The 1st IEEE Global Conference on Consumer Electronics 2012
Application of Bayesian Updating to Prioritized Process Suspension at the OS Boot Up Time Hiroshi Itoh
Atsushi Kaneko
Research & Technology, Lenovo Japan Ltd. Yokohama, Japan
[email protected]
TVT Development, Lenovo Japan Ltd. Yokohama, Japan
[email protected] On the contrary, our process suspension approach would pick certain ‘Must-Run’ processes according to a black list to define them. This black list can be easily maintained because it is not incrementally updated even if users install a new application. Table 1 shows the differences between a white list approach and our black list approach to determine which processes to be suspended. All processes except our black list or rules are basically suspended after loading the program files and their initialization.
Abstract— A process suspension approach is introduced by this paper to improve the OS boot up time. Two key factors are discussed to apply this approach. One is how to determine which processes can be suspended and resumed by external triggers. The other is how to recover from our incorrect decision to suspend some processes, resulting in deteriorating the OS boot up time unexpectedly, by using Bayesian Updating method.
I.
INTRODUCTION
In recent years, there has been a growing interest in using Solid State Drives (SSD) instead of Hard Disk Drives (HDD) as the secondary storage of client devices including not only mobile devices but also personal computers. As a result, the Operating System (OS) boot up time has been significantly improved, because the loading time of files from a SSD can be dramatically decreased [1].
TABLE 1. Check Items List Contents List Updates Complexity
However we can observe another problem that slows down the OS boot up time when many applications are registered by end users, even using a SSD. This is because the processor time and the usable memory space are limited per each process task, eventually resulting in increasing the memory data to be paged out and taking more time to execute each task. A special tool [2] is provided in order to restrict the running of programs at Android OS boot up time, and a special configuration mechanism [3] to enable the delay start of Windows services is provided in order to ease the rush of processes running at Windows OS boot up time.
White List Approach
Black List Approach
‘Not to run or Delayed’ processes/applications For all applications not to be run or delayed Complicated to consider some exceptional cases
‘Must-Run’ processes/applications For ‘Must-Run’ applications only Simple to be predefined
Fig. 1 shows the overall mechanism of our process suspend/resume controls of any detected processes to be suspended during a certain boot period. If a certain process is judged by our Process Control Core to be suspended according to the process categorization described in Section II, it will be suspended until three major external events are observed. The fourth event, called Boot (Complete) Timeout, is exceptionally used to resume all suspended processes when no successful boot completion time is observed by a certain threshold time after the OS boots up. This threshold value is typically defined as 40-45 seconds after the system power up to cancel all process suspensions. This Boot Timeout event is also used to judge if the boot time result is a S(Slow) result for our Bayesian Updating method described in Section IV.
In this paper we present our original idea to automatically prioritize and suspend processes as much as possible at Windows OS boot up time without any manual tuning like the above [2][3]. And then we present another idea to use Bayesian Updating method to determine which processes can be suspended according to the past boot time results. This idea was inspired from a Bayesian approach to identify and filter any spam e-mails which was originally introduced by the referenced paper [4]. II.
WHITE LIST APPROACH AND BLACK LIST APPROACH
Process Control Core:
Event Monitoring Core: IPC Activities
Suspend Process Identification
Resume Process Identification
Suspension Timer User Click Events
ORIGINAL IDEA OF PROCESS SUSPENSION
Suspend/Resume Controls Boot Timeout
A. Process Suspension Approach The above two methods [2][3] would pick certain applications not to run or to be delayed according to a white list to define them. Such a white list approach is less effective when users install many applications because they cannot manually maintain the list well for all the installed applications.
Suspend
Resume
Suspended Processes Suspended Processes Suspended Processes
Kernel Driver: IPC Object Monitoring
Figure 1. Process Suspend/Resume Mechanism
235
suspended. Group C is basically treated as the process group to be suspended. This group includes all other anonymous programs. However a certain process belonging to this group may be treated as ‘Must-Run’ if our Bayesian Updating
B. Three External Triggers for Process Resume There are three external triggers to resume the suspended processes normally. The other, Boot Timeout, is not normally observed. Fig. 2 shows the time series of these resume sequences during the OS boot time. Resume caused by User Click Events (All Processes)
Resume caused by IPC Activities (Per Process)
Resume after Suspension Timer expiration (Per Process)
Resume after Boot Complete Timeout (Exceptional)
Group A
Group B
Group C
Always Must-Run
Basically Must-Run
Bayesian Must-Run
Bayesian Suspend
Basically Suspend
Process Suspend
Process A Suspend
Power-On
Suspension Timer 30 sec. Process B Suspend
method indicates it should be ‘Must-Run’.
Process C Suspend Process D Suspend
Figure 3. Three Process Categories
Boot Complete Timeout (40-45 sec.)
IV. Figure 2. Time Series of Resume Sequences
A. Bayesian Updating Adaptation If our resume trigger mechanisms including the IPC monitor are perfect, our Bayesian Updating approach is not required. However Microsoft may introduce other new kernel objects to signal IPC events in the future versions of Windows. In this case, our IPC monitor should be updated. Or a core service-X may introduce another new process-Y module via Windows Update. In this case, the core service-X would not work well if the logic in the core service-X is waiting for the signal from the suspended process-Y.
The first and the most important one is to monitor the shared handles/objects being signaled by other running processes and to resume the signaled process only according to such signals. Our process suspension approach can be enabled only with this Inter-Process Call (IPC) activity monitor by our kernel driver module. The second one is to manage each expiration timer per suspend and to resume the suspended process after the timer is expired. The default expiration value of the time is approximately 30 seconds and it is enough to ease the rushed process running conditions at the OS boot up time. The third one is to monitor any user activities to manually start applications such as clicking icons on the desktop shell, i.e. Windows Explorer. When such activities are detected, our control program resumes all of the suspended processes immediately. Both rapid OS boot up without user interaction and normal responses to user’s demands to launch programs are accomplished by this trigger.
Bayes' theorem gives the relationship between the prior probabilities of A and B, P(A) and P(B), and the posterior probabilities of A given B and B given A, P(A|B) and P(B|A) as the following common formula (1). P(A|B) = P(B|A) P(A) / P(B)
(1)
Equation (1) would be easily expanded for H1(Must-Run), H2(Suspended), and R(Boot Time Result=Slow or Fast) as the following form (2). P(Hi|R) = P(R|Hi) P(Hi) / (P(R|H1) P(H1)+P(R|H2) P(H2)) (2)
These three triggers are appropriately used to resume the corresponding processes only, or all processes. For example, some independent startup programs could be suspended at OS boot up time and would not be resumed until its timer expiration because they have no signals from other services. Other programs which have some system callbacks could be also suspended but would be resumed according to the callback signal detection at the OS boot up time. III.
BAYESIAN UPDATING DISCUSSION
where i = 1, 2 and initially posterior probability P(H1|R) = P(H2|R) must be 0.5 because prior probability P(H1) = P(H2) is also 0.5 without any boot time observation. According to the and H2(Suspended) process native H1(Must-Run) characteristics, we can roughly estimate the likelihood values P(S|H1) = 0.8, P(F|H1) = 0.2, P(S|H2) = 0.2, and P(F|H2) = 0.8. Then we can observe the boot time result R as S(Slow) or F(Fast) with a certain boot time threshold. Either P(S|H1) or P(F|H1) is substituted to P(R|H1) and either P(S|H2) or P(F|H2) is substituted to P(R|H2) in (2) according to the boot time result.
PROCESS CATEGORIZATION
We can list up three process categories as shown in Fig. 3. Group A is always treated as the ‘Must-Run’ process group. This group includes OS System Process, Idle Process, other IPC services, security programs like virus-scan/firewall programs, and our process control program to be predefined in our name list. Group B is basically treated as the ‘Must-Run’ process group at first according to the Registry’s dependency list. However a certain process belonging to this group may be suspended if our Bayesian Updating method indicates it can be
P(H1|R) and P(H2|R) are calculated and they are used to determine whether a certain process can be suspended, (P(H1|R) P(S|Hi). It is more preferable to select a suspend combination Hi which has more suspended processes.
8.
Change the boot mode to Normal Mode: After changing the boot mode to Normal Mode, we can calculate the posterior probabilities P(Hi|R).
9.
Calculate the posterior probabilities P(Hi|R) per every OS boot: The posterior probabilities P(Hi|R) is calculated and monitored whether it is greater than 0.5 or not. If it is greater, this step 9 is repeatedly executed during every boot time. When P(Hi|R) is less than 0.5, we should consider that the current suspend combination Hi is invalid to meet our boot time criteria. This condition might be observed when users install new application programs and the newer process dependencies are established behind our control. In this case we must go to Step 10.
10. Reset the likelihood calculated process flags to ‘Unmarked’ and go to Step 1: These unmarked processes are treated as their likelihood values are currently invalid.
Register processes belonging to Group C: Pick and register N processes belonging to Group C. They are identified by excluding the predefined processes in Group A and the rule-based processes in Group B from all of running processes. If there are any likelihood calculated processes in this group, we must go to Step 6 immediately.
2.
4.
According to the above algorithm, let’s consider a simple example (N=3) in which we should have the following suspend combinations: H0: S(000) H1: S(001) H2: S(010) H3: S(100) H4: S(011) H5: S(110) H6: S(101) H7: S(111)
237
Then the observed likelihood values in Test Mode are shown as follows in Table 2. This means that H5 = S(110) suspend combination is a good candidate for normal boot up. After finding this kind of candidate, testing all of the suspend combinations can be immediately iterated from the viewpoint of actual implementations. TABLE 2.
users perform interactive activities without any system busy state immediately after the desktop screen is available. Then after about 50 seconds has passed since the OS boot up, all of the unnecessary processes at the OS boot time are resumed to execute their postponed tasks. Fig. 7 shows another example to illustrate both “Boot To Desktop” time when the desktop screen is ready and “Boot Complete” time when the system CPU usage is settled after “Boot To Desktop” time. The left 2 bars indicate our priority suspension feature disabled cases, and the right 2 bars indicate enabled cases.
LIKELIHOOD VALUES IN TEST MODE
P(R|Hi)
H0
H1
H2
H3
H4
H5
H6
H7
Fast
0.2
0.0
0.4
0.4
0.0
0.8
0.0
0.0
Slow
0.8
1.0
0.6
0.6
1.0
0.2
1.0
1.0
“Boot Complete” time is more improved than “Boot To Desktop” time because user installed applications are mainly started after “Boot To Desktop” time and we are able to suspend more processes after that time.
Next, all of the initial prior probabilities are set to 0.5 as follows because we cannot assume any priority. P(Hi) = 0.5
By introducing our Bayesian Updating method, Windows 7 boot up times were actually improved both for ThinkPad and ThinkCentre in the range from 25% to 40% [9] compared with the original boot up time without our method.
where i=0,1,2,3,4,5,6,7
Fig. 5 shows the posterior probability of P(H5|R) to be varied according to the observed boot time results. As long as the value is greater than 0.5, S(110) suspend combination is repeatedly used for the boot up in Normal Mode. The posterior probability of P(H5|R) has been decreased by the consecutive S(Slow) boot time results. These slow boot time results would be mainly caused by newly installed applications by end-users. Eventually, S(110) suspend combination is no longer valid and the newer suspend combinations (probably N > 3) should be evaluated to get their newer likelihoods every boot time in Test Mode.
OS Boot Complete (82sec.)
Fig. 6 (a) OS Boot Complete (26sec.)
Fig. 6 (b) Figure 6.
CPU Usage Transition Examples
50 43.83
45 Figure 5. S(110) Probability according to the Boot Time Results
40
Using our Bayesian updating algorithm, we can find the best suspend combinations to minimize OS boot time without any program information such as dependencies and/or parentchild relationships. This method has a big advantage because it is applicable to any future applications that are installed by end-users which are not recognized at our product shipping time.
35
Boot To Desktop [sec] Boot Complete [sec] 31.95
28.74
30
24.45
25 20 15 10
V.
PRIORITY SUSPENSION RESULTS
5
Fig. 6 shows CPU usage transition results per process during OS boot up time when our priority suspension feature is disabled in Fig.6 (a) and enabled in Fig. 6 (b), which are measured by Windows Performance Analyzer included in Windows SDK 7.1 [7] on our test machine [8].
0 w/o Rapid Boot Figure 7.
The Boot Complete Time [26 sec.] is obtained in Fig. 6 (b) case earlier than the one [82 sec.] in Fig. 6 (a) case which lets
238
w/ Rapid Boot
Boot To Desktop/Boot Complete Time Examples
VI.
CONCLUSION
REFERENCES [1]
This paper has proposed our unique process suspension method to prioritize the running processes in the Windows OS boot environment. Our method could determine which processes to be suspended without any program information such as the installed program dependencies and parent-child relationships by using our Bayesian Updating algorithm to find the most feasible suspend combination in a timely manner.
[2] [3] [4]
[5]
By eliminating any user/system program dependencies with our method, we could improve the Windows 7 boot up time for both ThinkPad and ThinkCentre.
[6]
ACKNOWLEDGEMENT We would like to thank Jeric Mark Calamba, John Mese, Matthew Lietzke, Egbert Jose Gracias, Derek Maynard, Junji Shibatani, Yuko Kimura, Hidetoshi Mori, Rod Waltermann and Mark C Davis for providing their design review, detailed comments, suggestions, and kindest support. We are also grateful to Noboru Kodama, Daryl Cromer, Junichi Asoh, Joe Pennisi, Jim Hunt and Dave Higgins for their constant support. Without their support, this paper would not be possible and our concept would not be fulfilled on any Lenovo products.
239
[7] [8] [9]
V. Kasavajhala, "Solid State Drive vs. Hard Disk Drive Price and Performance Study", Dell Technical White Paper, May 2011. Aaron, "Android Assistant", Google Play Store. Microsoft, "Services in Windows", Microsoft Technical White Paper, October 19, 2010. M. Sahami, S. Dumais, D. Heckerman, and E. Horvitz, "A Bayesian Approach to Filtering Junk E-Mail", In Learning for Text Categorization: Papers from the 1998 Workshop, 1998. T. Sherwood, E. Perelman, G. Hamerly, and B. Calder, "Automatically Chracterizing Large Scale Program Behavior", In Proceedings of the 10th International Conference on Architectural Support for Programming Languages and Operating Systems, Oct 2002. C.-K. Luk, R. Cohn, R. Muth, H. Patil, A. Klauser, G. Lowney, S.Wallace, V. J. Reddi, and K. Hazelwood. "Pin: Building Customized Program Analysis Tools with Dynamic Instrumentation", In Proceedings of PLDI 2005, pages 191–200, Chicago, Illinois, USA, June 2005. Microsoft, "Microsoft Windows SDK for Windows 7 and .NET FRW4", http://www.microsoft.com/en-us/download/details.aspx?id=8279 Lenovo ThinkPad T410: Intel Core i5, 2.4GHz; DDR3, 4GB; HDD 5400 rpm; Windows 7 Service Pack1, 64bit Lenovo, "Enhanced Experience 3.0 Overall features for ThinkPad", from Lenovo sales package, February 2012.
