WO2019113871A1

WO2019113871A1 - Sensor hub and memory system with reduced page swapping overhead

Info

Publication number: WO2019113871A1
Application number: PCT/CN2017/116085
Authority: WO
Inventors: Guangyu REN; Ke HAN; Hebo HU; Guangfu HU; Feng Xu
Original assignee: Intel Corporation
Priority date: 2017-12-14
Filing date: 2017-12-14
Publication date: 2019-06-20
Also published as: CN111108484A

Abstract

A sensor hub method to oversee operations of a plurality of sensors is described that includes swapping a higher priority page having higher priority code and/or data of the program code out of an embedded memory that the sensor hub operates out of after the higher priority page has remained idle in the embedded memory for a first period of time. The method also includes swapping a lower priority page comprising lower priority code and/or data of the program code out of the embedded memory after the lower priority page has remained idle in the embedded memory for a second period of time that is shorter than the first period of time.

Description

SENSOR HUB AND MEMORY SYSTEM WITH REDUCED PAGE SWAPPING OVERHEAD

Field of Invention

The field of invention pertains generally to computer science and more specifically to a sensor hub and memory system with reduced page swapping overhead.

Background

Computing systems are being designed to become more and more aware of their ambient surroundings. As such, system designers are interested in finding new ways to integrate various sensors and their management into the systems they are designing.

Figures

A better understanding of the present invention can be obtained from the following detailed description in conjunction with the following drawings, in which:

Fig. 1 shows a computing system having a sensor hub and embedded memory;

Fig. 2 shows a method for compiling program code to be executed by the sensor hub out of the embedded memory;

Fig. 3 shows different characteristics of different priority levels of program code to be executed by a sensor hub that operates out of an embedded memory;

Fig. 4a shows a page swapping method;

Fig. 4b shows a power saving page eviction method;

Fig. 4c shows a process for entering an S0ix state.

Detailed Description

Fig. 1 shows a depiction of computing system 100 having an integrated sensor hub 102. The integrated sensor hub 102 may be implemented as an embedded processor or embedded controller that executes program code that is specific to the various sensors 103_1 through 103_M that are integrated into the computing system 100. Here, a sensor can include any device that reacts to the computing system’s ambient environment. Examples include a thermometer (reacts to the computer’s ambient temperature) , accelerometer (reacts to the computer’s physical orientation and/or movement) , a transducer (reacts to pressure/force applied to the computer) , etc.

Each such sensor 103 typically has associated device driver software or similar firmware. The sensor hub 101 can therefore be viewed as a special purpose processor that offloads the burdens/tasks of sensor related program code execution from the computer’s general purpose CPU cores 104_1 through 104_N. By so doing, for instance, the general purpose CPUs 104 can be put to sleep while the integrated sensor hub 101 remains active. As such, the computing system is able to conserve power (CPU cores are asleep) while, at the same time, keep its sensor related functions operational. As such, as just one possibility, the computer 100 may conserve large amounts of power for extended periods of time with its general purpose CPUs being asleep, while, at the same time, being fully aware and cognizant of its ambient surroundings.

As with other processors, the integrated sensor hub 101 executes program code from a memory. More specifically, the integrated sensor hub 101 reads program code instructions from memory as it needs them. Similarly, the integrated sensor hub 101 reads the data that is operated upon by the program code from memory, and, updates to such data can be written back to memory.

As is known in the art, both program code and data for a processor’s software/firmware programs are stored as “pages” within a processor’s memory. Here, the processor’s memory has limited capacity (all of the program code and data associated with all of the software that could be executed by the processor cannot fit in memory) . In a traditional computing system, a general purpose processor core 104 will call up pages from non volatile mass storage 107 (e.g., a disk drive) that contains the program code instructions and data that it presently needs or believes it will need and place them into main memory 105 (also referred to as system memory 105) . Likewise, the general purpose processor 104 will cause pages that are presently in main memory 105 but whose associated program code and data are not believed to be imminently needed to be pushed out of main memory 105 and written back into non volatile mass storage 107. Thus, in a traditional computing system there exists page swapping behavior between the computer’s main memory 105 and mass storage 102.

According to one embodiment, the integrated sensor hub 101 operates out of a local embedded memory 102 (e.g., a static random access memory (SRAM) or an embedded dynamic random access memory (eDRAM) memory) as its primary processor memory and uses the computing system’s main memory 105 (e.g., double data rate (DDR) dynamic random access memory (DRAM) ) as a mass storage cache. As such, page swapping behavior 110 takes place between the local embedded memory 102 and the computing system’s main memory 105. Specifically, pages of program code and/or data that the sensor hub 101 imminently needs (or believes it will imminently need) are called up from the computing system’s main memory 105 and entered into the local memory 102. By contrast, pages of program code and/or data that the sensor hub 101 does not need (or does not believe it needs) are pushed out of the local embedded memory 102 and written back to the computing system’s main memory 105.

According to another embodiment, the sensor hub 101 can also operate out of the computing system’s main memory 105. In this case, the sensor hub has two operable memory regions: 1) a first faster access memory region 101 (the local embedded memory) ; and, 2) a second slower access memory region 105 (DRAM computer main memory) .

Here, to say that the sensor hub 101 “operates out of” a memory (or “executes out of” a memory) means that memory read/write instructions executed by the sensor hub 101 can be directly serviced by the memory (if no intervening processor cache has the sought for item) . Generally, such accesses are finer grained than mass storage accesses. For example, a memory request generally pertains to a finer grained amount of memory address space (e.g., a cache line composed of the data/code held at, e.g., sixteen, eight or fewer memory addresses, a byte addressable operation is specified by a memory write instruction, etc. ) . By contrast, accesses to mass storage 107 typically pertains to much larger “blocks” or “sectors” of code/data that consume a much larger amount of memory address space.

Regardless of whether the main memory 105 is used as a mass storage cache (first embodiment described above) or as a second region of memory that the sensor hub 101 operates out of (second memory described above) , the overall system will behave more optimally in terms of performance/efficiency if the pages that the sensor hub 101 most frequently accesses are kept in the embedded memory 102 for extended periods of time. That is, because the embedded memory 102 has lower access times than the main memory 105 from the perspective of the sensor hub 101, the sensor hub 101 will be able to execute the sensor related program code most efficiently. Additionally, there is generally apt to be more power consumption if the sensor hub operates out of main memory 105 because the main memory controller 106 and the main memory 105 must be turned on/active. By contrast, if the sensor hub 101 operates only out of the embedded memory 102, the main memory controller 106 and main memory 105 can be turned off. As such, there is a motivation to move pages having more frequently accessed code/data to the embedded memory 102 irrespective of whether the sensor hub can operate out of both

memories

102, 105 or just the embedded memory 102.

Unfortunately, page swapping behavior 110 in general between the main memory 105 and embedded memory 102 is itself a form of inefficiency (power is consumed moving data/code to a new location in the computer, the sensor hub 101 may stall while waiting for data/code that is located on a page being swapped in, etc. ) . Operational efficiencies are therefore gained by minimizing the page swapping behavior 110 in/out of the

memories

102, 105.

However, a challenge/problem exists in implementations where the embedded memory 102 is small in size and/or, as with SRAM, consumes a high amount of power. In these environments there is a propensity to swap pages (potentially even frequently accessed pages) out of the embedded memory 102 because of its small size. If the embedded memory 102 is designed to have various ones of its banks dynamically switch off to save power the capacity of the embedded memory 102 is reduced further still which exacerbates the problem.

As such, in various embodiments, mechanisms are put in place to keep the code/data that the sensor hub 101 most frequently accesses within the embedded memory 102 and prevent such high priority code/data from being swapped out of the embedded memory 102 as much as possible. Here, a simple least recently used page eviction policy (evict the page that has been resident in the embedded memory 102 for the longest time without an access having been made to it by the sensor hub 101) , by itself, may not accurately reflect which code/data is most frequently accessed by the sensor hub 101 (e.g., over a long run-time of the processor) .

Therefore, in various embodiments, a compiler that compiles the sensor hub’s program code deliberately streamlines the constructed code so that more frequently accessed items of code/data will remain in the embedded memory 102 for longer periods of time than less frequently accessed items of code/data even if some of the more frequently accessed items of code/data exhibit extended periods of time over which they are not accessed by the sensor hub 101.

According to a first code construction process, each of the different pages that are constructed by the compiler are given one of a number or priority levels. During runtime pages that have higher priority level are allowed to remain in the embedded memory 102 for longer periods of time without being accessed than lower priority pages. Here, according to a nominal background process, if the embedded memory 102 is full and a new page needs to be swapped into the embedded memory 102 from the computer’s main memory 105, the sensor hub 101 and/or the code executing on the sensor hub 102 will have to choose which page is to be swapped out of the embedded memory 102. As alluded to above, similar problems have been traditionally handled by evicting a least recently used item.

However, according to one embodiment, if a page is given a high priority it is not eligible to be swapped out of the embedded memory 102 unless some extended period of time has elapsed with the page being idle (not accessed by the sensor hub 101) where the extended period of time is longer than the amount of time other lower priority pages are allowed to be idle before being eligible for removal from the embedded memory 102. As such, a lower priority page may be swapped out of the embedded memory 102 while a higher priority page remains in the embedded memory 102 even though the higher priority page has sat idle in the embedded memory 102 for a longer period of time than the lower priority page.

As an example, a highest priority page setting may not permit a highest priority page to be swapped out of the embedded memory 102 unless it has been idle in the embedded memory 102 for at least 3 seconds, whereas, a lowest priority page setting has no such condition (e.g., a lowest priority page is eligible to be swapped out if it remains idle for . 5 seconds) . In this case, so long as the higher priority page is not idle for more than 3 seconds, the lowest priority page will always be chosen to be swapped out of the embedded memory 102 even if the lowest priority page has been idle for a shorter period of time than the highest priority page.

According to an alternative or combined embodiment, the compiler deliberately places higher priority program code and data on high priority pages and deliberately places lower priority program code and data on low priority pages. As such, the compiler deliberately constructs the code/data of the sensor hub’s program code with “designed for” priority levels. Here, higher priority code and data are generally the code and data that the compiler understands/believes will be more frequently accessed, while, lower priority code and data are generally the code and data that the compiler understands/believes will be less frequently accessed.

Here, the overall software/firmware to be executed by the sensor hub 101 may be a combination of different software programs, such as a combination of different device driver software/firmware programs for each of a number of different sensors. Whereas a traditional compiler would construct the pages such that only code/data from a same sensor’s driver are put on a same page, by contrast, the improved approach allows for the compiler to coalesce ( “merge” ) higher priority code snippets and data from different drivers onto a same page. Here, a snippet may be viewed, e.g., as a finer grained, smaller section of program code/data as compared to a total amount of code/data that could fit on a single page. Thus, for instance, more frequently accessed snippets of code and data for different device drivers may be placed on a high priority page as constructed by the compiler.

So doing, ideally, prevents the existence of a page having both high priority code/data and low priority code/data. Here, if a number of pages having both high priority and low priority code/data existed that exceeded the capacity of the embedded memory 102, the system would continually “thrash” page swapping operations 110 as it would repeatedly need to swap in a page having high priority code/data at the expense of another page that also contained high priority code/data and that would need to be swapped out of the embedded memory in order to make room for the page being swapped in.

Fig. 2 shows a software compilation process 200 for the software/firmware of an integrated sensor hub that includes the features described above. Here, the respective software programs for different sensors (e.g., the device drivers for different sensors) are broken down into respective higher priority snippets of code and data and lower priority snippets of code and data 201. The higher priority snippets of program code and data from across the different software programs are then coalesced onto higher priority pages and the lower priority snippets of program code and data from the same different software programs are coalesced onto lower priority pages 202.

Each of the pages are labeled with a respective priority identifier and permitted idle times in embedded memory are assigned for each priority level 203. Policy code is also inserted into the software that the sensor hub uses to determine which page to swap out of the embedded memory 102 in a situation where a page needs to be swapped into the embedded memory 102 but no free space exists in the embedded memory 102 to accommodate the new page (it is filled with other pages) . Note that various ones of the parameters described above (e.g., assignment of specific priority levels to specific pages, assignment of specific idle times to specific priority levels) may be provided by a programmer, may be assigned automatically by the compiler, or, some combination of both.

In further embodiments, only snippets of code and data having a same priority value are placed on a same page. As such, snippets of code/data having different priority levels are not allowed to be placed on a same page which should prevent large amounts of low priority code consuming valuable embedded memory space because it resides on a page that also contains a small piece of code/data that is frequently used. In other embodiments, an effort is made to place snippets of code/data having same priority level as much as possible on a same page. If any (e.g., last remaining) pages have snippets of code/data of different priority values the page is assigned the priority level of its higher priority code/data.

Fig. 3 shows an embodiment of a priority scheme that articulates characteristics of different code/data priority levels and identifies a permitted idle time policy for each priority level. As observed in Fig. 3, in an embodiment, a highest priority level P0 is reserved for program code that is always active ( “always on” or never put to sleep) . This type of program code is usually characteristic of deep, basic, core operations of the sensor hub itself (e.g., the sensor hub’s real time operating system, the primary loop of the sensor hub’s application software, the page swapping program code including the inserted code used to determine which page to swap out of the embedded memory, the sensor hub’s memory management (e.g., the code that oversees which addresses called out by the sensor hub’s software map to which physical addresses in the embedded memory and the external main memory) , sensor hub power management program code) .

A next highest priority level P1 is reserved for program code that may be put to sleep but is nevertheless frequently used. This type of program code is usually characteristic of the basic routines of the individual sensors themselves (e.g., the main loop of a particular sensor’s device driver, power management program code for a particular sensor, basic status program code (e.g., awake/alive watchdog timers, etc. ) or the entire routines of frequently used sensors (e.g., an accelerometer) . Certain sensors may also have higher priority than other sensors. Thus, for instance, program code associated with one sensor may be assigned priority level (s) that are consistently higher than the priority level (s) assigned to the program code of another sensor.

A lowest priority level P2 is reserved for program code that may be put to sleep and is not frequently used. This type of program code is usually characteristic of routines of the sensor hub or individual sensors that are only active in response to rare occasions (e.g., annual maintenance/calibration program code, special purpose/operating mode program code (e.g., a particular advanced algorithm that is used if the sensor experiences an extreme ambient condition, etc. ) .

Also depicted in Fig. 3 is an exemplary idle period for each priority level that specifies how long a page having a particular priority level may remain in the embedded memory before it is eligible for being swapped out of the embedded memory. As can be seen in Fig. 3, higher priority pages are permitted to be idle in the embedded memory for longer periods of time before being eligible for eviction from the embedded memory than lower priority pages. In an embodiment, the idle time thresholds are configured as settings into the page swapping program code algorithm of the sensor hub. Additionally, the pages themselves have associated meta data including information that specifies what priority level each page has been assigned to. This information is also referred to by the sensor hub’s page swapping program code.

In various embodiments the assignment of program code/data to a specific priority level is accomplished with hints and/or specific directives provided by a programmer who is overseeing the compilation process. That is, the programmer may individually assign certain segments of the larger program with certain priority levels based, e.g., on the characteristics discussed above. Alternatively or in combination the compiler may also automatically assign priority levels based on characteristics of the code. For example, indicia of high priority code may include the program of a basic code loops whose branches jump to large sections of program code, program code that moves pages between the embedded memory and the external memory, program code that accesses parts of the computer other than a sensor (which may be indicative of an operating system or other core process, etc. ) .

In a further embodiment, the sensor hub 101 has different performance states each having its own trade-off between performance and power consumption (where, generally, each step-up in performance corresponds to a corresponding step-up in power consumption) . For example, in one embodiment, the embedded memory 102 has multiple memory banks. In a highest performance state, all banks of the embedded memory 102 are active, while, at a lowest performance state one or no banks are active (in the case of the later, if the sensor hub 101 is architected to operate directly out of main memory 105, the sensor hub 101 can still execute program code even if all embedded memory banks are inactive) .

During operation in the highest performance state, the paging algorithm brings pages into the embedded memory 102 without evicting any pages until the embedded memory 102 is full of pages. Once the embedded memory 102 is full of pages the aforementioned priority based swap out policy is used to swap in any next page.

In embodiments where the sensor hub 101 cannot operate directly out of the main memory 105 and can only operate directly out of the embedded memory 102, any page miss during execution of the sensor hub code will cause a next page to be swapped into embedded memory 102 from main memory 105 at the cost of eviction of a page from the embedded memory 102 if the embedded memory is full. In embodiments where the sensor hub 101 can operate directly out of the main memory 105, according to one approach, if a page to be operated out of is resident in main memory 105 and has a higher priority than a page in the embedded memory 102, the higher priority page is swapped with the lower priority page (the particular lower priority page to be swapped out could be identified as the lowest priority page in the embedded memory 102 having the longest current idle time) .

In a low power operational mode of the sensor hub 101, in various embodiments, the sensor hub 101 actively attempts to minimize the number of active embedded memory banks. In this case, if any page in the embedded memory 102 has an idle period that exceeds the threshold for that page’s priority level, the sensor hub will evict the page from embedded memory 102. The sensor hub 101 may then coalesce surviving pages into as few banks as possible to “free up” a bank (such that is has no pages) and then deactivate the bank.

At least in embodiments where the sensor hub 101 operates directly out of the embedded memory 102 but not the main memory 105, if the sensor hub 101 needs data/code on a page that is not in the embedded memory 102 (page miss) the needed page is called up from the main memory 105 and placed in the embedded memory 102. If all pre-existing pages in the embedded memory 102 are still within their allotted idle threshold, the newly called up page will be added to the set of pages that are already existing in the embedded memory 102. If there is not enough available space in the set of embedded memory banks that are activated, another embedded memory bank is activated to accommodate the newly called up page. In an alternative embodiment where the sensor hub 101 is also capable of operating directly out of the main memory 105, highest/higher priority pages may be called up to the embedded memory 102 but lower priority pages are not (at least in a low power mode, the sensor hub 101 accesses data/code on low priority pages directly from the main memory 105) .

Note that in various embodiments the main memory 105 may be partially or wholly implemented with an emerging non volatile memory technology that is faster than traditional FLASH and therefore is suitable for main/system memory applications (e.g., non volatile memory having storage cells composed of chalcogenide, resistive random access memory (ReRAM) , ferroelectric random access memory (FeRAM) , magnetic random access memories (e.g., spin transfer torque RAM (STT-RAM) ) , etc. ) . Such non volatile memory may be three-dimensional (e.g., stack storage cells in the metallurgy of the semiconductor die) and be able to operate as a true system memory (e.g., is byte addressable, is physically accessed with cache lines of data) rather than traditional mass storage (which is physically accessed with larger “sectors” or “blocks” of data) .

Even so, in embodiments where the sensor hub 101 only operates out of the embedded memory 102, such non volatile main memory practically emulates a mass storage resource for the sensor hub and embedded memory processor/memory system. That is, pages are swapped into volatile embedded memory to be operated on and swapped out of volatile embedded memory and stored in a non volatile storage resource when not needed. When a page is swapped out of embedded memory 102 and written back to non volatile main memory 105, the state of that page is preserved even if there is a system power failure.

Note that with respect to Fig. 1, any of the CPU cores 104, main memory controller 106, graphics processor unit (GPU) , main memory control hub and peripheral controller that includes the sensor hub 101 and embedded memory 102 may be integrated on a same semiconductor chip (e.g., a system-on-chip (SoC) ) . In other embodiments, the sensor hub may be integrated on a semiconductor chip that lacks various ones of these components (such as the GPU or includes only one general purpose core) . Such a stripped down SoC or other semiconductor chip may be a semiconductor chip that is integrated within a smart appliance as opposed to a traditional computer.

Software and/or firmware executing on an integrated sensor hub 101 (or other functional block having an instruction execution pipeline to execute program code) of processor may perform any of the functions described above. The software/firmware that is executed by the sensor hub may be permanently stored or quasi-permanently stored in non volatile memory or storage of the computing system. For example, as observed in Fig. 1, the software/firmware that is executed by the sensor hub 101 may be stored in a same non volatile memory 111, such as a FLASH memory, that stores the computing system’s Basic Input/Output System (BIOS) . During system boot-up the software/firmware that is executed by the sensor hub 101 may be read from the non volatile memory 111 and stored in the embedded memory 102 and/or the main memory 105.

Figs. 4a, 4b and 4c show different methodologies for a sensor hub that executes out of the embedded memory 102 but not the main memory 105. The methodology of Fig. 4a pertains to a nominal (higher power) performance state in which the sensor hub is not actively trying to run the embedded memory at its lowest power. According to the methodology of Fig. 4a, if there is a page miss 401 (code/data desired by the sensor hub is not in the embedded memory) , the page having the desired code/data is swapped in 404 if free space exists in the embedded memory 402. By contrast, if free space does not exist in the embedded memory 402, the sensor hub will swap the lowest priority page that has remained idle the longest in the embedded memory 403 out of the embedded memory, and then swap the desired page into the embedded memory 404.

The methodology of Fig. 4b pertains to lower performance state operation in which the sensor hub actively tries to run the embedded memory at its lowest power. According to the methodology of Fig. 4b, the sensor hub periodically scans the embedded memory seeking to swap out idle page (s) . Here, a timer sets the periodicity of the scan. Upon expiration of the timer and the associated interrupt 401, the sensor hub scans the embedded memory looking for any pages that have been idle for longer than the amount of time that has been allotted for their respective priority level 402. If no such pages exist the process is repeated upon a next timer expiration. If such pages exist they are swapped out of the embedded memory and if any embedded memory bank (s) can be switched off as a consequence of the space being freed up in the embedded memory from the page (s) being swapped out the bank (s) are switched off.

Fig. 4c shows a very low power or lowest power operational power state that the sensor hub may operate according to. Here, as is known in the art, different computing system components have different power states where, e.g., the S0 state is the only operable state and S1, S2, etc. power states correspond to increasingly deeper sleep states in which the component consumes less power with each deeper sleep state but also takes longer to return to the active S0 state. Another power state, referred to as an “S0ix” state, is a system power state used for “active idling” . While in this state, that larger computing system is typically not performing any real work (e.g., resulting from external stimulus provided to the computing system) , but at the same time, keeps certain basic/primary functions alive/active so that, e.g., if a sudden external stimulus is provided very little time is consumed for the component to respond with increased performance capability.

In the case, when the system enters the S0ix state, in various embodiments, all sensor hub pages except the highest priority P0 pages are demoted from the embedded memory to the external memory 421. As discussed above, many P0 routines are for always-on basic/foundational functions. With substantially only such routines in embedded memory the sensor hub should largely be idling (not performing any real work) but can quickly begin performing real work should the need exist. With the sensor hub idling when the system is idling in an S0ix state, should the system suddenly have to respond to some external stimuli and return to its normal S0 power state, if the sensor hub suddenly needs to perform real work, lower priority pages containing the program code/data used to implement the real work can be quickly called up from external memory and placed into embedded memory. In various embodiments, the system enters an S0ix state because of recent user and/or network inactivity but the system’s wireless network modem is kept active in case any new wireless communications are suddenly received by the system. Alternative embodiments of the method of Fig. 4c may not be associated with an S0ix state specifically but some other (e.g., non industry standard) low power idle state.

Embodiments of the invention may include various processes as set forth above. The processes may be embodied in machine-executable instructions. The instructions can be used to cause a general-purpose or special-purpose processor (such as the aforementioned integrated sensor hub) to perform certain processes. Alternatively, these processes may be performed by specific hardware components that contain hardwired or programmable logic circuitry for performing the processes, or by any combination of such logic and/or processor components. With respect to the sensor hub specifically, the various methods described above as being performed by sensor hub software may instead be performed in hardware by the sensor hub with dedicated hardwired or programmable logic circuitry.

Elements of the present invention may also be provided as a machine-readable medium for storing the machine-executable instructions. The machine-readable medium may include, but is not limited to, floppy diskettes, optical disks, CD-ROMs, and magneto-optical disks, FLASH memory, ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, propagation media or other type of media/machine-readable medium suitable for storing electronic instructions. For example, the present invention may be downloaded as a computer program which may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection) .

In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Claims

A computing system, comprising:

a) a plurality of general purpose processing cores;

b) a main memory controller;

c) a plurality of sensors;

d) a sensor hub to execute program code for the sensors;

e) an embedded memory coupled to the sensor hub, the sensor hub to execute the program code out of the embedded memory;

f) non volatile storage to store the program code, the program code comprising instructions that when executed by the sensor hub cause the sensor to perform a method, comprising:

swapping out a higher priority page comprising higher priority code and/or data of the program code out of the embedded memory after the higher priority page has remained idle in the embedded memory for a first period of time; and,

swapping out a lower priority page comprising lower priority code and/or data of the program code out of the embedded memory after the lower priority page has remained idle in the embedded memory for a second period of time that is shorted than the first period of time.
The computing system of claim 1 wherein the higher priority page does not contain lower priority code and/or data of the program code.
The computing system of claim 1 wherein the lower priority page does not contain higher priority code and/or data of the program code.
The computing system of claim 1 wherein the first time period Is greater than one second and the second time period is less than one second.
The computing system of claim 1 wherein the method further comprises:

swapping out a medium priority page comprising medium priority code and/or data of the program code out of the embedded memory after the medium priority page has remained idle in the embedded memory for a third period of time that is less than the first time period but greater than the second time period.
The computing system of claim 1 wherein the program code comprises multiple pages each assigned to one of a plurality of different priority levels, each priority level assigned a different amount of time it is permitted to be idle in the embedded memory before being eligible to be evicted from the embedded memory.
The computing system of claim 1 wherein the sensors includes any of:

a thermometer;

an accelerator;

a transducer.
A machine readable storage medium containing program code that when processed by a sensor hub to oversee operations of a plurality of sensors causes the sensor hub to perform a method, comprising:

swapping a higher priority page comprising higher priority code and/or data of the program code out of an embedded memory that the sensor hub operates the program out of after the higher priority page has remained idle in the embedded memory for a first period of time; and,

swapping a lower priority page comprising lower priority code and/or data of the program code out of the embedded memory after the lower priority page has remained idle in the embedded memory for a second period of time that is shorter than the first period of time.
The machine readable medium of claim 8 wherein the higher priority page does not contain lower priority code and/or data of the program code.
The machine readable medium of claim 8 wherein the lower priority page does not contain higher priority code and/or data of the program code.
The machine readable medium of claim 8 wherein the first time period Is greater than one second and the second time period is less than one second.
The machine readable medium of claim 8 wherein the method further comprises:

swapping a medium priority page comprising medium priority code and/or data of the program code out of the embedded memory after the medium priority page has remained idle in the embedded memory for a third period of time that is less than the first time period but greater than the second time period.
The machine readable medium of claim 8 wherein the program code comprises multiple pages each assigned to one of a plurality of different priority levels, each priority level assigned a different amount of time it is permitted to be idle in the embedded memory before being eligible to be evicted from the embedded memory.
A machine readable medium containing program code that when processed by a computing system causes the computing system to perform a method, comprising:

extracting higher priority snippets of program code and data and lower priority snippets of program code from respective programs for a plurality sensors;

merging certain higher priority snippets of program code and data from different ones of the programs onto a same high priority page;

merging certain lower priority snippets of program code and data from different ones of the programs onto a same low priority page;

assigning a first amount of time for the high priority page to be idle in an embedded memory;

assigning a second amount of time for the low priority page to be idle in an embedded memory, the second amount of time less than the first amount of time.
The machine readable medium of claim 14 wherein the higher priority snippets are not written to be put to sleep.
The machine readable medium of claim 14 wherein the lower priority snippets are written to be put to sleep.
The machine readable medium of claim 14 wherein the higher priority snippets implement a main loop of the program code.
The machine readable medium of claim 14 wherein the lower priority snippets perform a special purpose advanced computation.
The machine readable medium of claim 14 further comprising permitting a program to label the high priority page as a high priority page.
The machine readable medium of claim 14 further comprising permitting a program to label the low priority page as a low priority page.
A semiconductor chip, comprising:

a sensor hub to execute program code for a plurality of sensors;

an embedded memory coupled to the sensor hub, the sensor hub to execute the program code out of the embedded memory, the sensor hub to:

swap out a higher priority page comprising higher priority code and/or data of the program code out of the embedded memory after the higher priority page has remained idle in the embedded memory for a first period of time; and,

swap out a lower priority page comprising lower priority code and/or data of the program code out of the embedded memory after the lower priority page has remained idle in the embedded memory for a second period of time that is shorted than the first period of time.
The semiconductor chip of claim 21 further comprising a general purpose processing core.
The semiconductor chip of claim 22 wherein the sensor is integrated within a peripheral control hub.
The semiconductor chip of claim 23 wherein the higher and lower pages are to be swapped out to a memory that is coupled to a memory controller that is embedded on the semiconductor chip.