Having debugged the new implementation, and ensured the system is stable
with the new page allocation method, we evaluate PAVM's effectiveness
at reducing energy footprints of processes.
We expect that the active node set, , for each
task will tend to localize to the task's preferred node set,
.
However, this is far from what we see.
Table 2 shows a partial snapshot of the processes in a
running system, and, for each process , indicates the nodes in sets
and
, as well as the number of pages allocated on
each node.2 It is clear from the snapshot that each process
has a
large set of active nodes, where
is much larger than the
corresponding
. This causes a significantly larger energy
footprint for each process than what we have originally anticipated.
Nevertheless, since most pages are allocated in the preferred nodes, and
none of the processes use all nodes in the system, we still consider
this a working system that provides opportunities to put nodes into
low-power modes and conserve energy. However, it is not as effective as
we would like, due to the fact that for each process, there is a set of
pages scattered across a large number of nodes.
To understand this ``scattering'' effect, we need to investigate how memory is used in the system. In most systems, a majority of the system memory is occupied by user processes. In turn, most of these pages are used to hold memory-mapped files, which include binary images of processes, dynamically-loaded libraries (DLL), as well as memory-mapped data files. To reduce the size of the executable binaries on disk and the processes' cores in memory, DLLs are extensively used in Linux and most other modern operating systems. The scattering effect we observe is a result of the extensive use of DLLs combined with the behavior of the kernel-controlled page cache.
The page cache is used to buffer blocks previously read from the disk, so on subsequent accesses, they can be served without going to the disk, greatly reducing file access latencies. When a process requests a block that is already in the page cache, the kernel simply maps that page to the requesting process's address space without allocating a new page. Since the block may have been previously requested by any arbitrary process, it can be on any arbitrary node, resulting in an increased memory footprint for the process. Unfortunately, this is not limited to shared data files, but also to DLLs, as these are basically treated as memory-mapped, read-only files. The pages used for DLLs are lazily loaded, through demand paging. So, when two processes with disjoint preferred nodes access the same library, the pages will scatter across the union of the two preferred node sets, depending on the access pattern of the processes and which process first incurred the page-fault to load a particular portion of the library into the page cache.
In the following sections, we describe the incremental changes we make to reduce the memory/energy footprint for each process by using DLL aggregation and page-migration techniques. We then discuss how to reduce overhead of these new techniques.