Swap Token - Advanced Operating Systems and Kernel Applications - page 102

Figure 9. The memory performance of gzip and vortex in their concurrent execution managed with
swap token.

havior as it is shown in the dedicated environment,
where its RSS curve was almost overlapped with
its MAD curve (see Figures 1 and 2), we believe
this RSS curve represents its real memory de-
mands for its effective execution (or its working
set size). There are two reasons for this: (1) The
page fault rate is significantly lower than that in
its counterpart experiment for the original system.
Even when RSS curve of vortex is considerably
lower than its MAD curve after the 470 th second,
its page fault rates are lowered by at least 70%
compared with those measured at the same ex-
ecution stage in the original system. (2) The RSS
curve of vortex is consistent with its NAP curve in
the dedicated environment. The NAP curve was
increased much slowly than MAD curve, which
reflects that the recently accessed memory size
did not increase as MAD did. Therefore, the gap
between its RSS and MAD curves in Figure 9
was enlarged in its late execution stage, where its
fluctuation was caused by the content change of
its working set. While eliminating the thrashing
quickly, the swap token distinguished true and
false LRU pages, and only kept the working set
of the protected process in the memory, rather
than simply pinned all of its pages in memory.

The experiments also show that the execution
times of both programs are significantly reduced
by the swap token compared with the times in the
original Linux. The slowdown of gzip is 2.63 (a
reduction of 50%), and is 1.83 for vortex (a reduc-
tion of 52%). The page fault reductions for gzip
and vortex are 45% and 80%, respectively.
Figure 10 presents the memory performance
measured by MAD and RSS of concurrently
running programs bit-r and gcc when the swap
token is introduced.At the execution time of 146 th
second, the first RSS spike of gcc caused many
page faults for both processes due to memory
shortage. The token was taken by gcc after this
moment. Figure 10 shows that gcc quickly built
up its working set, reflected by keeping its first
RSS spike with a short delay after taking the
token, while bit-r sharply decreased its RSS
during this short period of time. Process gcc
established its working set in its second spike
more quickly than it did in its first spike, due to
the difference between their reference behaviors:
gcc accessed its working set more frequently in
the second spike than it did in the first spike.
The swap token mechanism attempted to reduce
false LRU pages without affecting the ability of