CN111108484A

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

Info

Publication number: CN111108484A
Application number: CN201780095327.3A
Authority: CN
Inventors: 任光宇; 韩柯; 胡和波; 胡光福; 徐锋
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2017-12-14
Filing date: 2017-12-14
Publication date: 2020-05-05
Also published as: WO2019113871A1

Abstract

A sensor hub method of supervising operation of a plurality of sensors is described, the method comprising swapping a higher priority page with program code out of an embedded memory from which the sensor hub operates after the higher priority page has been idle in the embedded memory for a first period of time. The method also includes swapping lower priority pages including lower priority code and/or data of the program code out of the embedded memory after the lower priority pages have 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

Technical Field

The field of the invention relates generally to computer science and, more particularly, to a sensor hub and memory system with reduced page swapping overhead.

Background

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

Drawings

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 illustrates a computing system with a sensor hub and embedded memory;

FIG. 2 illustrates a method for compiling program code to be executed by a sensor hub from an embedded memory;

FIG. 3 illustrates different characteristics of different priority levels of program code to be executed by a sensor hub operating from embedded memory;

FIG. 4a illustrates a page swapping method;

FIG. 4b illustrates a power saving page eviction method;

fig. 4c shows a process for entering the S0ix state.

Detailed Description

FIG. 1 shows a depiction of a computing system 100 with an integrated sensor hub 102. The integrated sensor hub 102 may be implemented as an embedded processor or embedded controller that executes program code specific to the various sensors 103_1 through 103_ M integrated into the computing system 100. Here, a sensor can comprise any device that reacts to the ambient environment of the computing system. Examples include thermometers (reacting to the ambient temperature of the computer), accelerometers (reacting to the physical orientation and/or movement of the computer), transducers (reacting to pressure/force applied to the computer), and the like.

Each such sensor 103 typically has associated device driver software or similar firmware. The sensor hub 101 can thus be viewed as a dedicated processor that offloads the burden/task of sensor-related program code execution from the general-purpose CPU cores 104_1 to 104_ N of the computer. By doing so, for example, the general purpose CPU 104 can be put to sleep while the integrated sensor hub 101 remains active. As such, the computing system can save power (the CPU core is asleep) while keeping its sensor-related functions operational. As such, as just one possibility, the computer 100 may save a significant amount of power over an extended period of time by having its general purpose CPU sleep, while fully paying attention to and recognizing its surroundings.

As with the other processors, the integrated sensor hub 101 executes program code from memory. More specifically, the integrated sensor hub 101 reads program code instructions from memory as they are needed. Similarly, the integrated sensor hub 101 reads data from memory that is operated on by program code, and updates to such data can be written back to memory.

As is well known in the art, both program code and data for a software/firmware program of a processor are stored as "pages" within the memory of the processor. Here, the memory of the processor has a limited capacity (all program codes and data associated with all software that the processor can execute cannot be loaded into the memory). In a conventional computing system, the general purpose processor core 104 will call pages from a non-volatile mass storage device 107 (e.g., a disk drive) that contains program code instructions and data that it currently 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 currently in main memory 105 but whose associated program code and data are not considered urgent to be pushed out of main memory 105 and written back into the non-volatile mass storage device 107. Thus, in conventional computing systems, there is a page swapping behavior between the main memory 105 of the computer and the mass storage device 102.

According to one embodiment, the integrated sensor hub 101 operates from a local embedded memory 102 (e.g., Static Random Access Memory (SRAM) or embedded dynamic random access memory (eDRAM) memory) as its main 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. Thus, the page swap behavior 110 is conducted between the local embedded memory 102 and the main memory 105 of the computing system. Specifically, pages of program code and/or data that are urgently needed by the sensor hub 101 (or that it is deemed urgently needed) are called from the main memory 105 of the computing system and entered into the local memory 102. In contrast, pages of program code and/or data that are not needed (or not considered needed) by the sensor hub 101 are pushed out of the local embedded memory 102 and written back into the main memory 105 of the computing system.

According to another embodiment, the sensor hub 101 is also operable from the main memory 105 of the computing system. In this case, the sensor hub has two operable memory areas: 1) a first faster access memory area 101 (local embedded memory); and 2) a second slower access memory area 105 (DRAM computer main memory).

Herein, saying that the sensor hub 101 "operates from memory" (or "executes from memory") means that memory read/write instructions executed by the sensor hub 101 can be directly contributed by memory (if no intermediate processor cache has a look-up for an item). Generally, such accesses are more granular than mass storage access. For example, memory requests are generally associated with a finer amount of memory address space (e.g., cache lines composed of data/code held at, for example, sixteen, eight, or fewer memory addresses, byte addressable operations specified by memory write instructions, etc.). In contrast, accesses to mass storage device 107 are typically associated with much larger "blocks" or "sectors" of code/data that consume much larger amounts of memory address space.

Regardless of whether the main memory 105 is used as a mass storage cache (the first embodiment described above) or as a second region of memory from which the sensor hub 101 operates (the second memory described above), the overall system will perform better in terms of performance/efficiency if the pages most frequently accessed by the sensor hub 101 are maintained in the embedded memory 102 for an extended period of time. That is, since the embedded memory 102 has a lower access time than the main memory 105 from the perspective of the sensor hub 101, the sensor hub 101 will be able to most efficiently execute the sensor-related program code. Additionally, if the sensor hub is operating from main memory 105, there is generally a tendency for more power consumption because the main memory controller 106 and the main memory 105 must be turned on/active. In contrast, if the sensor hub 101 operates only from the embedded memory 102, the main memory controller 106 and the main memory 105 can be shut down. Thus, there is an incentive to move pages with more frequently accessed code/data to the embedded memory 102, regardless of whether the sensor hub is capable of operating from both memories 102, 105 or from just the embedded memory 102.

Unfortunately, the page swap behavior 110 between the main memory 105 and the embedded memory 102 is generally an inefficient form in itself (moving data/code to a new location in the computer consumes power, the sensor hub 101 may stop while waiting for data/code on the page being swapped in, etc.). By minimizing the page swap behavior 110 into/out of the memory 102, 105, operational efficiency is thus obtained.

However, challenges/problems exist in implementations where the embedded memory 102 is small in size and/or consumes a large amount of power as with SRAM. In these environments, there is a tendency to swap out pages (potentially even frequently accessed pages) from the embedded memory 102 due to its small size. The capacity of the embedded memory 102 is further reduced if the embedded memory 102 is designed to have various ones of its banks (banks) dynamically turned off to save power, which exacerbates the problem.

Thus, in various embodiments, the following mechanisms are proposed: the code/data most frequently accessed by the sensor hub 101 is kept within the embedded memory 102 and such high priority code/data is prevented from being swapped out of the embedded memory 102 as much as possible. Here, a simple least recently used page eviction policy (evicting a page that has been resident in embedded memory 102 for the longest time that has not been accessed by sensor hub 101) may not itself accurately reflect which code/data is most frequently accessed by sensor hub 101 (e.g., during a long run time of the processor).

Thus, in various embodiments, a compiler compiling program code for a sensor hub intentionally simplifies processing built code such that more frequently accessed items of code/data will remain in embedded memory 102 for a longer period of time than less frequently accessed items of code/data, even if some more frequently accessed items of code/data exhibit an extended period of time in which they are not accessed by sensor hub 101.

According to the first code construction process, each of the different pages constructed by the compiler is given a given one of a number or a priority level. During runtime, pages with higher priority levels are allowed to remain in the embedded memory 102 for longer periods of time than lower priority pages without being accessed. 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 main memory 105 of the computer, the sensor hub 101 and/or code executing on the sensor hub 102 will have to select which page will be swapped out of the embedded memory 102. As alluded to above, similar problems have traditionally been addressed by evicting the least recently used item.

However, according to one embodiment, if a page is given a high priority, it does not qualify for being swapped out of the embedded memory 102 unless a certain extended period of time has elapsed during which the page is 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 idle before qualifying for removal from the embedded memory 102. Thus, even if a higher priority page has been idle in the embedded memory 102 for a longer period of time than a lower priority page, the lower priority page may be swapped out of the embedded memory 102 while the higher priority page remains in the embedded memory 102.

As an example, unless the highest priority page has been idle in the embedded memory 102 for at least 3 seconds, the highest priority page setting may not allow it to be swapped out of the embedded memory 102, while the lowest priority page setting has no such condition (e.g., the lowest priority page qualifies as being swapped out if it remains idle for.5 seconds). In this case, the lowest priority page will always be selected 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, as long as the higher priority page has not been idle for more than 3 seconds.

According to alternative or combined embodiments, the compiler intentionally places higher priority program code and data on high priority pages and intentionally places lower priority program code and data on low priority pages. Thus, the compiler intentionally constructs code/data for the program code of the sensor hub with a "design for" priority level. Here, higher priority code and data is generally code and data that a compiler understands/considers to be accessed more often, while lower priority code and data is generally code and data that a compiler understands/considers to be accessed less often.

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 plurality of different sensors. However, conventional compilers will construct pages such that only code/data from drivers of the same sensor is placed on the same page, in contrast to improved schemes that allow compilers to merge ("fuse") higher priority code segments and data from different drivers onto the same page. Here, a section may be considered, for example, as a more granular, smaller section (section) of program code/data than the total amount of code/data that can be loaded on a single page. Thus, for example, more frequently accessed pieces of code and data for different device drivers may be placed on a high priority page as constructed by a compiler.

Doing so desirably prevents the presence of pages having both high priority code/data and low priority code/data. Here, if the number of pages with both high and low priority code/data present exceeds the capacity of the embedded memory 102, the system will constantly "thrash" (thrash) the page swap operation 110, as it will repeatedly need to swap in a page with high priority code/data at the expense of another page that also contains high priority code/data and will need to be swapped out of the embedded memory to make room for the page being swapped in.

FIG. 2 illustrates a software compilation process 200 for software/firmware of an integrated sensor hub incorporating the features described above. Here, respective software programs for different sensors (e.g., device drivers for different sensors) are subdivided into respective higher priority segments of code and data and lower priority segments of code and data, 201. Subsequently, higher priority segments from program code and data across different software programs are merged onto a higher priority page and lower priority segments from program code and data of the same different software programs are merged onto a lower priority page, 202.

Each of the pages is labeled with a respective priority identifier and each priority is assigned an allowed idle time in the embedded memory, 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 the event that 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 (which is populated with other pages). Note that various ones of the parameters described above (e.g., assignment of a particular priority level to a particular page, assignment of a particular idle time to a particular priority level) may be provided by a programmer, may be automatically assigned by a compiler, or some combination of the two.

In other embodiments, only the segments of code and data having the same priority value are placed on the same page. Thus, not allowing pieces of code/data with different priority levels to be placed on the same page would prevent a large amount of low priority code from consuming valuable embedded memory space as it resides on pages that also contain a small piece of code/data that is often used. In other embodiments, efforts are made to place as many pieces of code/data with the same priority level on the same page as possible. If any (e.g., the last remaining) page has a fragment of code/data of a different priority value, that page is assigned a priority level of its higher priority code/data.

FIG. 3 illustrates an embodiment of a priority scheme that clearly characterizes the different code/data priority levels and identifies the allowed idle time policies for each priority level. As observed in fig. 3, in an embodiment, the 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 typically has characteristics of deep, basic, core operation of the sensor hub itself (e.g., the real-time operating system of the sensor hub, the main loop of the application software of the sensor hub, page swapping program code that contains inserted code to determine which pages to swap out of embedded memory, memory management of the sensor hub (e.g., code that oversees which addresses evoked by the software of the sensor hub map to which physical addresses in embedded memory and external main memory), sensor hub power management program code).

A highest priority level P1 is reserved for program code that can be put to sleep but is still used often. This type of program code typically has characteristics of the underlying routines of the individual sensors themselves (e.g., the main loop of the device driver for a particular sensor, the power management program code for a particular sensor, the underlying status program code (e.g., a awake/active watchdog timer, etc.), or all routines of frequently used sensors (e.g., accelerometers).

The lowest priority level P2 is reserved for program code that can be put to sleep and is not used often. This type of program code typically has the characteristics of routines of the sensor hub or individual sensors that are active only in response to rare opportunities (e.g., annual maintenance/calibration program code, special/operating mode program code (e.g., specific high-level algorithms that are used if the sensors encounter extreme environmental conditions, etc.)).

Also depicted in FIG. 3 is an exemplary idle period for each priority level that specifies how long a page with a particular priority level may remain in the embedded memory before it is eligible to be swapped out of the embedded memory. As can be seen in fig. 3, higher priority pages are allowed to sit idle in the embedded memory for a longer period of time before conforming to evictions from the embedded memory than lower priority pages. In an embodiment, the idle time threshold is configured as a setting in a page swap program code algorithm to the sensor hub. In addition, the pages themselves have associated metadata that contains information specifying what priority level each page has been assigned. This information is also referenced by the page swapping program code of the sensor hub.

In various embodiments, the assignment of program code/data to particular priority levels is accomplished through hints and/or specific indications provided by a programmer overseeing the compilation process. That is, a programmer may assign certain priority levels individually to certain segments (segments) of a larger program, e.g., based on the characteristics discussed above. Alternatively or in combination, the compiler may also automatically assign priority levels based on the characteristics of the code. For example, indicia of high priority code may include a program of a basic code loop whose branches jump to a large section of program code, program code to move pages between embedded memory and external memory, program code to access portions of a computer (rather than a sensor) (which may indicate an operating system or other core process, etc.).

In a further embodiment, the sensor hub 101 has different performance states, each with its own trade-off between performance and power consumption (where generally each increment in performance corresponds to a corresponding increment in power consumption). For example, in one embodiment, the embedded memory 102 has multiple memory banks. In the highest performance state, all banks of the embedded memory 102 are active, while in the lowest performance state, one bank or no bank is active (in the latter case, if the sensor hub 101 is configured to operate directly from the main memory 105, the sensor hub 101 is able to 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 priority-based swap-out policy mentioned above is used to swap in any next page.

In embodiments where the sensor hub 101 cannot operate directly from the main memory 105 and can only operate directly from the embedded memory 102, if the embedded memory is full, any page misses during execution of the sensor hub code will cause the next page to be swapped from the main memory 105 into the embedded memory 102 at the expense of evicting the page from the embedded memory 102. In embodiments where the sensor hub 101 can operate directly from the main memory 105, according to one scheme, if the page to be operated from resides in the main memory 105 and has a higher priority than the 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 can be identified as the lowest priority page having the longest current idle time in the embedded memory 102).

In a low power mode of operation 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, the sensor hub will evict a page from the embedded memory 102 if any page in the embedded memory 102 has an idle period that exceeds a threshold for the priority level of the page. The sensor hub 101 may then consolidate the surviving pages into as few banks as possible to "empty" the bank (so that it has no pages) and then retire the bank.

At least in embodiments where the sensor hub 101 operates directly from the embedded memory 102 instead of 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 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 assigned idle threshold, the newly called page will be added to the set of pages already present in the embedded memory 102. If there is not enough space available in the set of activated embedded memory banks, another embedded memory bank is activated to accommodate the newly invoked page. In an alternative embodiment, where the sensor hub 101 can also operate directly from the main memory 105, the highest/higher priority page may be called to the embedded memory 102, but the lower priority pages are not called (at least in the low power mode, the sensor hub 101 accesses data/code on the low priority pages directly from the main memory 105).

Note that in various embodiments, main memory 105 may be partially or fully implemented by emerging non-volatile memory technologies (e.g., non-volatile memory with memory cells composed of sulfides, resistive random access memory (ReRAM), ferroelectric random access memory (FeRAM), magnetic random access memory (e.g., spin transfer torque RAM (STT-RAM)), etc.) that are faster than traditional FLASH and thus suitable for main/system memory applications. Such non-volatile memory may be three-dimensional (e.g., a stacked memory location in the metallurgy of semiconductor dies) and can operate as a true system memory (e.g., byte-addressable, physically accessed in cache lines of data) rather than a traditional mass storage device (which is physically accessed through larger "sectors" or "blocks" of data).

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

Note that with respect to fig. 1, any of the CPU core 104, the main memory controller 106, the Graphics Processor Unit (GPU), the main memory control hub, and the peripheral controller (which includes the sensor hub 101 and the embedded memory 102) may be integrated on the same semiconductor chip (e.g., a system on a chip (SoC)). In other embodiments, the sensor hub may be integrated on a semiconductor chip that lacks various of these components (such as a GPU or a semiconductor chip that contains only one general purpose core). Such a reduced SoC or other semiconductor chip may be a semiconductor chip integrated within a smart device that is different from a traditional computer.

Software and/or firmware executing on the integrated sensor hub 101 (or other functional block having an instruction execution pipeline to execute program code) of the processor may perform any of the functions described above. The software/firmware executed by the sensor hub may be permanently stored or quasi-permanently stored in a non-volatile memory or storage device of the computing system. For example, as observed in fig. 1, the software/firmware executed by the sensor hub 101 may be stored in the same non-volatile memory 111 that stores the basic input/output system (BIOS) of the computing system, such as FLASH memory. During system boot, software/firmware 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.

Fig. 4a, 4b and 4c illustrate different methodologies for a sensor hub executed from the embedded memory 102 instead of the main memory 105. The methodology of FIG. 4a is related to a nominal (higher power) performance state in which the sensor hub is not actively attempting to run the embedded memory at its lowest power. According to the methodology of fig. 4a, if there is a page miss (code/data desired by the sensor hub is not in the embedded memory), 401, then if there is free space in the embedded memory, 402, then the page with the desired code/data is swapped in, 404. In contrast, if there is no free space in the embedded memory, 402, the sensor hub will swap out the lowest priority page from the embedded memory that has remained idle the longest in the embedded memory, 403, and then swap the desired page into the embedded memory, 404.

The methodology of FIG. 4b is related to lower performance state operation where the sensor hub actively attempts 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 the idle page(s). Here, a timer sets the periodicity of the scan. Upon timer expiration and associated interrupts, 401, the sensor hub scans the embedded memory for any pages that have been idle for an amount of time that exceeds the amount of time that has been allocated for their respective priority levels, 402. If no such pages exist, the process is repeated upon expiration of the next timer. If such pages exist, they are swapped out of the embedded memory, and if any embedded memory bank can be closed because space is vacated in the embedded memory because the page(s) were swapped out, then the bank(s) are closed.

Fig. 4c shows a very low power or lowest power operating power state from which the sensor hub may operate. Here, as is known in the art, different computing system components have different power states, where, for example, the S0 state is the only operational state, and the power states S1, S2, etc., correspond to increasingly deeper sleep states in which the components consume less power through each of the deeper sleep states, but also take longer to return to the active S0 state. Another power state, referred to as the "S0 ix" state, is the system power state for "active Idle". While in this state, the larger computing system is typically not performing any actual work (e.g., resulting from external stimuli provided to the computing system), certain basic/primary functions are kept alive/active at the same time, such that, for example, if a sudden external stimulus is provided, very little time is consumed to cause the component to respond with increased performance capabilities.

In this case, when the system enters the S0ix state, in various embodiments, all sensor hub pages except the highest priority P0 page are demoted from the embedded memory to the external memory 421. As discussed above, many of the P0 routines are used for basic/basic functions that are always on. With essentially only such routines in embedded memory, the sensor hub should be largely idle (not performing any actual work), but if it needs to be present, can quickly begin performing actual work. In the case where the sensor hub is idle while the system is idle in the S0ix state, if the sensor hub suddenly has to respond to some external stimulus and return to its normal S0 power state, a lower priority page containing program code/data to implement the actual work can be quickly called from external memory and placed into embedded memory if the sensor hub suddenly needs to perform the actual work. In various embodiments, the system enters the S0ix state due to recent user and/or network inactivity, but the system' S wireless network modem remains active to prevent the system from suddenly receiving any new wireless communications. An alternative embodiment of the method of fig. 4c may not be specifically associated with the S0ix state, but rather with 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 implemented in machine-executable instructions. The instructions can be used to cause a general-purpose or special-purpose processor, such as the integrated sensor hub mentioned above, to perform certain processes. Alternatively, the processes may be performed by specific hardware components that contain hardwired or programmable logic for performing the processes, or by any combination of such logic and/or processor components. With particular regard to the sensor hub, the various methods described above as being performed by the sensor hub software may in turn be performed in hardware by the sensor hub through dedicated hardwired or programmable logic circuits.

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 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

1. A computing system comprising:

a) multiple general-purpose processing cores;

b) main memory controller;

c) multiple sensors;

d) a sensor hub for executing program code for said sensor;

e) an embedded memory coupled to the sensor hub for executing the program code from the embedded memory;

f) a non-volatile storage device for storing said program code, said program code comprising instructions which, when executed by said sensor hub, cause said sensor to perform a method comprising the steps of:

After a higher priority page including higher priority code and/or data of the program code has remained idle in the embedded memory for a first period of time, the higher priority page is removed from the embedded memory high-priority page swapping out; and,

After a lower priority page including the lower priority code and/or data of the program code has remained idle in the embedded memory for a second time period shorter than the first time period, from all The lower priority page is swapped out in the embedded memory.

2. The computing system of claim 1, wherein the higher priority page does not contain lower priority code and/or data for the program code.

3. The computing system of claim 1, wherein the lower priority page does not contain higher priority code and/or data for the program code.

4. The computing system of claim 1, wherein the first period of time is greater than one second and the second period of time is less than one second.

5. The computing system of claim 1, wherein the method further comprises:

After a medium priority page including medium priority code and/or data of said program code has remained idle in said embedded memory for a number of times less than said first time period but greater than said second time period After three time periods, the medium priority page is swapped out from the embedded memory.

6. The computing system of claim 1, wherein the program code includes a plurality of pages each assigned to one of a plurality of different priority levels, each priority level assigned It is allowed to sit idle in the embedded memory for varying amounts of time before being evicted.

7. The computing system of claim 1, wherein the sensor comprises any of the following:

thermometer;

accelerator;

transducer.

8. A machine-readable storage medium containing program code that, when processed by a sensor hub to supervise the operation of a plurality of sensors, causes the sensor hub to perform a method comprising:

After a higher priority page of higher priority code and/or data including the program code has remained idle in the embedded memory for a first period of time, swapping the higher priority page out of the sensor the embedded memory from which the hub operates the program; and,

After a lower priority page including the lower priority code and/or data of the program code has remained idle in the embedded memory for a second time period shorter than the first time period, all The lower priority pages are swapped out of the embedded memory.

9. 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.

10. 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.

11. The machine-readable medium of claim 8, wherein the first period of time is greater than one second and the second period of time is less than one second.

12. The machine-readable medium of claim 8, wherein the method further comprises:

After a medium priority page including medium priority code and/or data of said program code has remained idle in said embedded memory for a number of times less than said first time period but greater than said second time period After three time periods, the medium priority page is swapped out of the embedded memory.

13. The machine-readable medium of claim 8, wherein the program code includes a plurality of pages each assigned to one of a plurality of different priority levels, each priority level being assigned a The memory is allowed to sit idle in the embedded memory for varying amounts of time before it is evicted.

14. A machine-readable medium containing program code that, when processed by a computing system, causes the computing system to perform a method comprising:

Extract higher priority segments of program code and data and lower priority segments of program code from corresponding programs for multiple sensors;

fusing certain higher priority fragments of program code and data from different ones of the programs on the same high priority page;

fusing certain lower priority fragments of program code and data from different ones of the programs on the same low priority page;

assigning a first amount of time that the high-priority page will be idle in embedded memory;

A second amount of time that the low-priority page will be idle in embedded memory is assigned, the second amount of time being less than the first amount of time.

15. The machine-readable medium of claim 14, wherein the higher priority segment is not written to be put to sleep.

16. The machine-readable medium of claim 14, wherein the lower priority segment is written to be put to sleep.

17. The machine-readable medium of claim 14, wherein the higher priority segment implements a main loop of the program code.

18. The machine-readable medium of claim 14, wherein the lower priority segments perform dedicated high-level computations.

19. The machine-readable medium of claim 14, further comprising allowing a program to mark the high priority page as a high priority page.

20. The machine-readable medium of claim 14, further comprising allowing a program to mark the low priority page as a low priority page.

21. A semiconductor chip, comprising:

A sensor hub to execute program code for multiple sensors;

an embedded memory coupled to the sensor hub to execute the program code from the embedded memory, the sensor hub to perform the following operations:

22. The semiconductor chip of claim 21, further comprising a general purpose processing core.

23. The semiconductor chip of claim 22, wherein the sensor is integrated within a peripheral control hub.

24. The semiconductor chip of claim 23, wherein the upper and lower pages are to be swapped out to memory coupled to a memory controller embedded on the semiconductor chip.