Patent Application
20210342192
This application relates to operating systems of information handling systems and, more particularly, to executing software applications on information handling systems.
As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to human users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing human users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different human users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific human user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
Users of information handling systems expect instant response from their systems and want their software applications ready and fully available for use when they need to start working. Current application environments compress the application data files onto the disk to optimize storage space. When a given software application is called by the system user, the compressed application is expanded into memory and the application performs initialization routines. These initialization routines can sometimes take a delay of seconds to several minutes, depending on factors such as the system drive media type, available amount of system memory, available CPU bandwidth, etc. This delay can lead to decreased user productivity and a perceived lack of quality and performance from the system. In particular, launching of an application at time of user need negatively impacts productivity more and more as the delay in application launch increases, and this increasing delay contributes to perceived slow PC performance which may result in calls to tech support and associated costs. Launching an application automatically (without user input) may cause confusion and break the user's workflow.
It is known to use an operating system (OS) to cache recently terminated software applications on an information handling system. Specifically, the OS retains a recently terminated application in system memory to improve subsequent load speed of that retained application. However, this only speeds up restart of an application, such as in case of accidental application termination.
Disclosed herein are systems and methods that may be implemented to pre-launch a given software application in a background state on an information handling system when the given application is predicted to be needed by a user of the information handling system. Using the disclosed systems and methods, the given software application may be pre-loaded into system memory and host execution space in a background state before the system user actually needs to use the given software application, and so that it is loaded and ready for foreground use when it is called for (i.e., needed) by the system user. This is in contrast to conventional methodology that only caches recently terminated applications in system memory.
Using the disclosed systems and methods, a background software service may in one embodiment be executed on a host programmable integrated circuit (e.g., such as a central processing unit) to predictively perform automatic pre-launching of a given software application (without any system user interaction) to reduce the time required for startup of the given application at the time it is needed by the system user. Advantageously, the given software application may be so pre-launched without exposing the system user to any displayed visual artifacts or other noticeable system behavior from the software application that can cause user distraction.
In one exemplary embodiment, a background software service may be executed on a host programmable integrated circuit to predictively perform automatic pre-launching of a given software application into a background application window maintained in a background virtual desktop environment of the information handling system before the given software application is called for (i.e., needed) by the system user, e.g., such as a within an inactive Microsoft Windows 10 operating system (OS) virtual desktop that is separate from the current active primary desktop running on the system. When the system user is ready to use and calls for launch of the given pre-launched application, the application window for the given application may be moved from the inactive background virtual desktop to the primary or active foreground desktop of the information handling system. Alternatively, when the system user calls for launch of the given application, the virtual desktop may be made active so that the input/output (I/O) foreground for the system user is switched from the current primary desktop to the virtual desktop where the given software application was originally rendered. In either case, this embodiment may be implemented without modifications to a conventional software application (e.g., such as conventional word processing application, conventional spreadsheet application, conventional presentation application, etc.). Rather, an unmodified conventional application may be launched in normal fashion into a background virtual desktop that is not discernible to the user, where it remains loaded and hidden from the system user until called by the system user.
In another exemplary embodiment, a background software service may be executed on a host programmable integrated circuit to predictively cause automatic pre-launching of a given software application before the given software application is called for (i.e., needed) by the user into a minimized background processing state by sending the given application a start reason indication that is recognizable by the given application as a pre-launch command. Such a start reason indication may be sent by the background software service, for example, via a new OS application lifecycle event (e.g., OnPreLaunch), via a command line switch, etc., In any case, the start reason indication may be sent to notify the given application that this is a pre-launch event (rather than a user launch event). In this embodiment, the given application may be configured (e.g., such as by modifying the programming of the code of a conventional software application, or by programming the original code of a new software application) to recognize this received start reason indication as a pre-launch-to-background state command, rather than a launch-to-foreground command.
In this embodiment, the programming of the code of the given application may be further configured to respond to receipt of the pre-launch event by immediately executing time and processing-intensive operations (e.g., such as graphics user interface pre-load, network prefetching, etc.) that are necessary for background execution of the given application, but without performing any other processing activities that would expose the system user to discernible system behavior or actions generated by the given application that might distract the system user from their current work, i.e., such that the pre-launched background application is hidden from the system user. Examples of such user-discernible system behavior or actions that may be suppressed or omitted during application pre-launch include, but are not limited to, production of sounds and/or display of a visual interface such as a splash screen, an application window, one or more task bar elements, etc. Thereafter, when the system user calls for launch of the given pre-launched application at a future time-of-need, most of the time and processing-intensive tasks required for complete launch of the given application from scratch will have already been executed, and startup time to launch the given application into foreground state from its pre-launched background state will therefore be quicker than would otherwise be the case.
In either of the above exemplary embodiments, the background software service may be further programmed to detect when OS resource/s (e.g., system memory, CPU processing, etc.) are being constrained on the information handling system and, if the system user has not yet called for launching of the given pre-launched application, the software service may then choose to automatically terminate the given pre-launched application (again without any system user interaction) so as to release the OS resources that it has been consuming. This allows the constrained system resources to be reclaimed when these system resources are needed for other processes and the user has not yet called and launched the given application into the foreground.
In one respect, disclosed herein is a method, including: operating an information handling system by executing an operating system (OS) and one or more foreground applications on a programmable integrated circuit of the information handling system; collecting input data from operation characteristics of the information handling system; determining if the collected input data indicates an upcoming need for one or more identified given applications that are not currently called for by a system user of the information handling system and that are not executing on a programmable integrated circuit of the information handling system; then pre-launching the one or more identified given applications as background applications executing on the programmable integrated circuit before the identified given applications are called for by the system user only if the collected input data indicates an upcoming need for the one or more identified given applications, the presence of the one or more pre-launched background applications being hidden from the system user and not accepting input from the system user; and then responding to a call from the system user for at least one of the one or more identified given applications by transferring the identified given application to be a foreground application executing on the programmable integrated circuit that is visible to the system user and that accepts input from the system user.
In another respect, disclosed herein is an information handling system, including: at least one programmable integrated circuit; and non-volatile memory coupled to the programmable integrated circuit. The at least one programmable integrated circuit may be programmed to: execute an operating system (OS) and one or more foreground applications, collect input data from operation characteristics of the information handling system, determining if the collected input data indicates an upcoming need for one or more identified given applications that are not currently called for by a system user of the information handling system and that are not executing on the at least one programmable integrated circuit of the information handling system; then pre-launch the one or more identified given applications as background applications executing on the at least one programmable integrated circuit before the identified given applications are called for by the system user only if the collected input data indicates an upcoming need for the one or more identified given applications, the presence of the one or more pre-launched background applications being hidden from the system user and not accepting input from the system user; and then respond to a call from the system user for at least one of the one or more identified given applications by transferring the identified given application to be a foreground application executing on the at least one programmable integrated circuit that is visible to the system user and that accepts input from the system user.
As shown in
In
In the illustrated embodiment, host programmable integrated circuit 110 may be coupled to an external or internal (integrated) display device 140 (e.g., LCD or LED display or other suitable display device) depending on the particular configuration of information handling system 100. In such an embodiment, integrated graphics capability may be implemented by host programmable integrated circuit 110 to provide visual images (e.g., a graphical user interface, static images and/or video content) to a system user. However, in other embodiments, a separate programmable integrated circuit (e.g., such as graphics processor unit “GPU”) may be coupled between host programmable integrated circuit 110 and display device 140 to provide graphics capability for information handling system 100.
PCH 150 controls certain data paths and manages information flow between components of the information handling system 100. As such, PCH 150 may include one or more integrated controllers or interfaces for controlling the data paths connecting PCH 150 with host programmable integrated circuit 110, system storage 160, input/output (I/O) devices 170 (e.g., keyboard, mouse, trackpad, etc.) forming at least a part of a user interface for the information handling system, network interface (I/F) device 171, embedded controller (EC) 181, and NVM 190, e.g., where BIOS firmware image and settings may be stored together with other components including ACPI firmware, one or more application pre-launch policies 192 and one or more application termination policies 194. It will be understood that application pre-launch policies 192 and application termination policies 194 may be alternatively stored on any other non-volatile storage of system 100, e.g., such as system storage 160.
In one embodiment, PCH 150 may include a Serial Peripheral Interface (SPI) controller and an Enhanced Serial Peripheral Interface (eSPI) controller. In some embodiments, PCH 150 may include one or more additional integrated controllers or interfaces such as, but not limited to, a Peripheral Controller Interconnect (PCI) controller, a PCI-Express (PCIe) controller, a low pin count (LPC) controller, a Small Computer Serial Interface (SCSI), an Industry Standard Architecture (ISA) interface, an Inter-Integrated Circuit (I2C) interface, a Universal Serial Bus (USB) interface and a Thunderbolt™ interface.
As shown in
Also shown present in
A power source for the information handling system 100 may be provided via an external power source (e.g., mains power) and an internal power supply regulator, and/or by an internal power source, such as a battery. As shown in
Embedded controller (EC) 181 is coupled to PCH 150 and may be configured to perform functions such as power/thermal system management, etc. EC 181 may also be configured to execute program instructions to boot information handling system 100, load application firmware from NVM 190 into internal memory, launch the application firmware, etc. In one example, EC 181 may include a processing device for executing program instructions to perform the above stated functions. Although not strictly limited to such, processing device of EC 181 may be implemented as a programmable integrated circuit (e.g., a controller, microcontroller, microprocessor, ASIC, etc., or as a programmable logic device “PLD” such as FPGA, complex programmable logic device “CPLD”, etc.).
As further shown in
Once pre-launched into inactive virtual desktop 120, a background software application 122 remains in the inactive virtual desktop 120 until it is either moved with user interface (UI) elements to active primary desktop 130 under the control of background service 102 upon launching of the application 122 by the system user (e.g., by mouse clicking on a displayed application icon), or is terminated according to termination policy 194 under the control of monitoring logic 106 of background service 102 to release needed system resources for other purposes. When background application 122 is moved with UI elements from inactive virtual desktop 120 to active primary desktop 130, the application 122 becomes a foreground application that is discernible to the system user on the primary desktop 130 by generating visual images on display device 140 and/or accepting user input from I/O devices 170.
In another embodiment, the state of inactive virtual desktop 120 may be changed from inactive to active under the control of background service 102, at which time the application 122 becomes a foreground application that is discernible to the system user on the now active virtual desktop 120 by generating visual images on display device 140 and/or accepting user input from I/O devices 170. At the same time, the state of primary desktop 130 may be changed (together with its applications 132) from active to inactive under the control of background service 102. In a further embodiment, it is possible to establish multiple different virtual desktops 120 simultaneously executing in the background on host programmable integrated circuit 110 (together with their respective different software application/s 122), and then to alternate between making the state of each of these multiple different virtual desktops 120 active one at a time (together with their respective different software application/s 122) under the control of background service 102 as needed by the system user.
In the illustrated embodiment of
Next, in step 304, predictive service 104 collects designated predictive input data gathered from operation characteristics of information handling system 100, e.g., such as data collected from various foreground applications 132 and/or other processes that are designated by pre-launch policies 192 as being indicative of system user behavior that is predictive of upcoming user need for one or more given application/s 122. For example, one pre-launch policy 192 may designate that an upcoming teleconference calendar entry is predictive of a system user need for a telecommunications (VoIP) application (e.g., such as Microsoft Skype) and a multi-user collaboration application (e.g., such as Microsoft OneNote), and may also designate the amount of time in advance of the scheduled teleconference (e.g., 15 minutes in advance) that the telecommunications application and multi-user collaboration application are to be pre-launched. In this regard, a pre-defined pre-launch policy 192 may designate times to pre-launch one or more given application/s 122 based on identity of different types of events or other actions (and combinations thereof) gathered from operation characteristics of information handling system 100 as predictive input data.
After collecting the designated predictive input data, predictive service 104 determines in step 306 if the collected predictive input data and pre-launch policies 192 indicate a need for pre-launching of a given application 122. If not, then methodology 300 repeats to step 304. However, if predictive service 104 determines in step 306 that the collected predictive input data does indicate a need for pre-launch of a given application 122 according to a particular pre-launch policy 192, then methodology 300 identifies this given application 122 and proceeds to step 308 described below. As an illustration, according to the example pre-launch policy 192 described above, predictive service 104 will in step 306 identify the telecommunications application and multi-user collaboration application described in the above example when the current calendar date and time of day is within 15 minutes in advance of the time scheduled in the calendar application entry for the upcoming teleconference.
Next, in step 308, background service 102 launches each of the identified given application/s 122 of step 306, loads them into system memory 180, and pushes them into a hidden inactive virtual desktop 120 as background application/s 122 that are hidden from the system user.
Thereafter, background service 102 determines in step 310 if the given background application/s 122 are currently (i.e., immediately) needed by the system user. Current system user need for launching the given background application/s 122 may be indicated to the background service 102, for example, by a system user action that calls the given background application/s 122, e.g., such as a user mouse click on an icon displayed on the user's active primary desktop 130 corresponding to each of the currently needed given background application/s 122.
If the background service 102 determines in step 310 that the given background application/s are currently needed by the system user, then methodology 300 proceeds to step 312 where the background service 102 switches the currently needed background application/s 122 from the inactive virtual desktop 120 to the active primary desktop 130 where they become visible in the foreground to the system user on the display device 140 and accept system user input via I/O devices 170 and/or touchscreen input in those embodiments where display device 140 is a touchscreen. Alternatively, in step 312 the background service 102 may switch the inactive virtual desktop 120 (together with its background application/s 122) to become an active primary desktop 130, in which case the previous given background application/s 122 become visible in the foreground to the system user on the display device 140 and accept system user input via I/O devices 170 and/or touchscreen input in those embodiments where display device 140 is a touchscreen. At this time, methodology 300 may return and repeat beginning at step 304 as shown in
However, if the background service 102 determines in step 310 that the given background application/s 122 are not currently needed by the system user, then methodology 300 proceeds to step 314 where the monitor service 106 of the background service 102 collects current resource usage data (e.g., utilization percentage of the host programmable integrated circuit 110, memory utilization percentage of system memory 180, etc.), e.g., from Microsoft Windows OS resource monitor utility or other corresponding OS resource monitor utility.
Next, in step 316, monitor service 106 determines if current usage of one or more of the system resources (e.g., host processing utilization, system memory utilization, etc.) exceeds one or more corresponding predefined resource utilization threshold values designated in application termination policies 194, such that ability does not exist for background application/s 122 to remain in system memory 180. In one embodiment, the type and value of one or more resource utilization threshold values may be predefined or provisioned (e.g., by a manufacturer or vendor of the information handling system 100, system user, etc.), and stored in NVM 190 or other suitable non-volatile storage. As an example, predefined resource utilization threshold values stored in application termination policies 194 may be 80% host (e.g., CPU) utilization and/or 80% system memory utilization, although it will be understood that any other greater or lesser resource utilization threshold values may be predefined as desired or needed for a given system instantiation.
If monitor service 106 determines in step 316 that current usage of one or more of the system resources exceeds one or more of the corresponding resource utilization threshold values designated in application termination policies 194, then background service 102 terminates and unloads the given background application/s 122 that are executing in the inactive virtual desktop 120, and methodology 300 returns and repeats beginning at step 304 as shown in
If monitor service 106 determines in step 316 that current usage of the system resources does not exceed any of the corresponding resource utilization threshold values designated in application termination policies 194, then methodology returns and repeats beginning at step 304 as shown. In this regard, it will be understood that additional different given background application/s 122 may be subsequently identified and pre-launched into inactive virtual desktop 120 according to different pre-launch policies 192. One example of such a different pre-launch policy 192 may be to pre-launch a graphics or photo-editing application (e.g., such as Adobe Photoshop) into inactive virtual desktop 120 when background service 102 detects that the system user has loaded a digital photograph into an image viewing application (e.g., such as Microsoft Windows 10 Photos app). Such an additional pre-launch policy 192 may be predefined (e.g., by system manufacturer or vendor, system user, etc.) in NVM 190 as previously described, or may alternatively be created later by background service 102 based on learned usage behavior over a period of time or number of system boots, e.g., such as when background service 102 detects that the system user loads the graphics or photo-editing application greater than 50% of the time after loading the image-viewing application to view a photograph. In any case, the subsequently-added given background application/s 122 may be queued together in step 308 with the existing executing given background application/s 122 already in inactive virtual desktop 120.
Next, in step 404, predictive service 104 collects designated predictive input data gathered from operation characteristics of information handling system 100 in the same manner as described for step 304 of
After collecting the designated predictive input data, predictive service 104 determines in step 406 if the collected predictive input data and pre-launch policies 192 indicate a need for pre-launching of a given application 222. If not, then methodology 400 repeats to step 404. However, if predictive service 104 determines in step 406 that the collected predictive input data does indicate a need for pre-launch of a given application 222 according to a particular pre-launch policy 192, then methodology 400 identifies this given application 222 in the same manner as described for step 306 of
Next, in step 408, background service 102 sends each of the identified given applications 222 a start reason indication that is recognizable by the identified given application 222 as a pre-launch command. Such as start reason indication may be sent, for example, via a new OS application lifecycle event (e.g., OnPreLaunch), via a command line switch, etc.
In step 410, each identified given application 222 receives and is programmed to recognize its respective received start reason indication as a pre-launch-to-background state command, rather than a launch-to-foreground command. At this time in step 410, each identified given application 222 responds to receipt of the pre-launch command by partially loading in a minimized background processing state hidden from the system user in which time and processing-intensive operations/functions necessary for background execution of the given application (e.g., such as data load, network acquisition, etc.) are loaded and executed, while limiting and delaying all screen write and I/O functions (e.g., such as display of graphics or other visuals on display device 140, accepting user input via I/O devices 170 and/or touchscreen, etc.) and any other functions that would expose the system user to discernible system behavior or actions generated by the given application/s 222 that might distract the system user from their current work.
Thereafter, background service 102 determines in step 412 if the given background application/s 222 are currently (i.e., immediately) needed by the system user. Similar to step 310 of
If the background service 102 determines in step 412 that the given background application/s 222 are currently needed by the system user, then methodology 400 proceeds to step 414 where the background service notifies the given application/s 222 to complete load of the given application/s 222 so that they become foreground applications 232 executing in a full foreground processing state on the active desktop 230. At this time background service 102 also releases all user interface (UI) related processes and functions to the given application/s 222 so as to allow them to be visually seen as foreground application/s 232 in the foreground on display device 140 together with any other user-discernible functions (e.g., such as production of sounds, etc.) and to accept user input via I/O devices 170 and/or touchscreen in those embodiments where display device 140 is a touchscreen. At this time, methodology 400 may return and repeat beginning at step 404 as shown in
However, if the background service 102 determines in step 412 that the given background application/s 222 are not currently needed by the system user, then methodology 400 proceeds to step 416 where the monitor service 106 of the background service 102 collects current resource usage data in the same manner as described for step 314 of
Next, in step 418, monitor service 106 determines if current usage of one or more of the system resources exceeds one or more of the corresponding resource utilization threshold values designated in application termination policies 194 in the same manner as described for step 316 of
If monitor service 106 determines in step 418 that current usage of the system resources does not exceed any of the corresponding resource utilization threshold values designated in application termination policies 194, then methodology returns and repeats beginning at step 404 as shown.
It will understood that the particular combination of steps of
It will also be understood that one or more of the tasks, functions, or methodologies described herein (e.g., including those described herein for components 110, 140, 171, 175, 181, etc.) may be implemented by circuitry and/or by a computer program of instructions (e.g., computer readable code such as firmware code or software code) embodied in a non-transitory tangible computer readable medium (e.g., optical disk, magnetic disk, non-volatile memory device, etc.), in which the computer program includes instructions that are configured when executed on a processing device in the form of a programmable integrated circuit (e.g., processor such as CPU, controller, microcontroller, microprocessor, ASIC, etc. or programmable logic device “PLD” such as FPGA, complex programmable logic device “CPLD”, etc.) to perform one or more steps of the methodologies disclosed herein. In one embodiment, a group of such processing devices may be selected from the group consisting of CPU, controller, microcontroller, microprocessor, FPGA, CPLD and ASIC. The computer program of instructions may include an ordered listing of executable instructions for implementing logical functions in an processing system or component thereof. The executable instructions may include a plurality of code segments operable to instruct components of an processing system to perform the methodologies disclosed herein.
It will also be understood that one or more steps of the present methodologies may be employed in one or more code segments of the computer program. For example, a code segment executed by the information handling system may include one or more steps of the disclosed methodologies. It will be understood that a processing device may be configured to execute or otherwise be programmed with software, firmware, logic, and/or other program instructions stored in one or more non-transitory tangible computer-readable mediums (e.g., data storage devices, flash memories, random update memories, read only memories, programmable memory devices, reprogrammable storage devices, hard drives, floppy disks, DVDs, CD-ROMs, and/or any other tangible data storage mediums) to perform the operations, tasks, functions, or actions described herein for the disclosed embodiments.
For purposes of this disclosure, an information handling system may include any instrumentality or aggregate of instrumentalities operable to compute, calculate, determine, classify, process, transmit, receive, retrieve, originate, switch, store, display, communicate, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for business, scientific, control, or other purposes. For example, an information handling system may be a personal computer (e.g., desktop or laptop), tablet computer, mobile device (e.g., personal digital assistant (PDA) or smart phone), server (e.g., blade server or rack server), a network storage device, or any other suitable device and may vary in size, shape, performance, functionality, and price. The information handling system may include random access memory (RAM), one or more processing resources such as a central processing unit (CPU) or hardware or software control logic, ROM, and/or other types of nonvolatile memory. Additional components of the information handling system may include one or more disk drives, one or more network ports for communicating with external devices as well as various input and output (I/O) devices, such as a keyboard, a mouse, touch screen and/or a video display. The information handling system may also include one or more buses operable to transmit communications between the various hardware components.
While the invention may be adaptable to various modifications and alternative forms, specific embodiments have been shown by way of example and described herein. However, it should be understood that the invention is not intended to be limited to the particular forms disclosed. Rather, the invention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims. Moreover, the different aspects of the disclosed systems and methods may be utilized in various combinations and/or independently. Thus the invention is not limited to only those combinations shown herein, but rather may include other combinations.
