Check out the new USENIX Web site. next up previous
Next: 5 Evaluation Results Up: 4 Implementation Previous: 4.4 Revision #2: Page Migration


4.5 Revision #3: Reducing Migration Overhead

Although page migration greatly reduces the energy footprints of processes, it triggers additional memory activity, which may undermine the energy savings obtained. Thus, we must consider ways to limit the actual number of migrations to keep its benefits without incurring too much of energy cost. In this section, we propose two solutions to reduce the number of page migrations.


Solution 1: The DLL aggregation technique described previously assumes libraries tend to be shared. Any library that is not shared will later be migrated to the process preferred nodes. This is not efficient for those applications that use proprietary dynamic libraries. We can keep track of the processes that cause a large number of page migrations, and then classify them further as private-page dominated and shared-page dominated. A process is private-page dominated when the number of private pages migrated is much larger than the migrated shared pages. It indicates that the pages this process uses are less likely to be shared, meaning that we should allocate pages on this process's preferred node and not automatically aggregate the library pages it uses.

On the other hand, if a process is shared-page dominated, it means that many shared pages were wrongfully migrated initially and later migrated back. For these processes, we want to inhibit the number of page migrations for shared pages to prevent future migrations to correct the initial migration decision.


Figure 5:  Cumulative distribution function of process life times.
\begin{figure}\centering\leavevmode
\epsfig{figure=./figs/short-lived.eps,width=2.7in}\end{figure}

Solution 2: It is widely known that processes are short-lived. Process lifetime is similar to what is shown in Figure 5 [27], where only 2% of all processes live more than 30 seconds. Instead of performing page migration for all processes, we only migrate pages on behalf of long-lived processes, since the energy spent on migrating pages for short-lived processes does not justify the resulting energy savings. Note that the implementation of kmigrated implicitly avoids migrating all processes, as it checks the system at most once every 3 seconds, and only when the system is not busy, thus avoiding most short-lived processes.


next up previous
Next: 5 Evaluation Results Up: 4 Implementation Previous: 4.4 Revision #2: Page Migration
2003-03-03