One - The Linux Kernel Archives

144 • Linux Symposium 2004 • Volume One
OOM.” On a large-memory Altix system, it can
easily take much longer than that to complete
the necessary calls to shrink_caches().
The result is that an Altix system never goes
OOM in spite of the fact that swap space is full
and there is no memory to be allocated.
It seemed to us that part of the problem here
is the amount of time it can take for a swap
full condition (readily detectable in try_
to_swap_out() to bubble all the way up
to the top level in try_to_free_pages_
zone(), especially on a large memory machine.
To solve this problem on Altix, we
decided to drive the OOM killer directly off
of detection of swap-space-full condition provided
that the system also continues to try to
swap out additional pages. A count of the
number of successful swaps and unsuccessful
swap attempts is maintained in try_to_
swap_out(). If, in a 10 second interval, the
number of successful swap outs is less than
one percent of the number of attempted swap
outs, and the total number of swap out attempts
exceeds a specified threshold, then try_to_
swap_out()) will directly wake the OOM
killer thread (also new in our implementation).
This thread will wait another 10 seconds, and
if the out-of-swap condition persists, it will invoke
oom_kill() to select a victim and kill
it. The OOM killer thread will repeat this sleep
and kill cycle until it appears that swap space
is no longer full or the number of attempts to
swap out new pages (since the thread went to
sleep) falls below the threshold.
In our experience, this has made invocation of
the OOM killer much more reliable than it was
before, at least on Altix. Once again, this implementation
was for Linux 2.4.21; we are in
the process of evaluating this problem and the
associated fix on Linux 2.6 at the present time.
Another fix we have made to the VM system
in Linux 2.4.21 for Altix is in handling
of HUGETLB pages. The existing implementation
in Linux 2.4.21 allocates HUGETLB
pages to an address space at mmap() time (see
hugetlb_prefault()); it also zeroes the
pages at this time. This processing is done by
the thread that makes the mmap() call. In
particular, this means that zeroing of the allocated
HUGETLB pages is done by a single
processor. On a machine with 4 TB of
memory and with as much memory allocated
to HUGETLB pages as possible, our measurements
have shown that it can take as long as
5,000 seconds to allocate and zero all available
HUGETLB pages. Worse yet, the thread that
does this operation holds the address space’s
mmap_sem and the page_table_lock for
the entire 5,000 seconds. Unfortunately, many
commands that query system state (such as ps
and w) also wish to acquire one of these locks.
The result is that the system appears to be hung
for the entire 5,000 seconds.
We solved this problem on Altix by changing
the implementation of HUGETLB page allocation
from prefault to allocate on fault. Many
others have created similar patches; our patch
was unique in that it also allowed zeroing of
pages to occur in parallel if the HUGETLB
page faults occurred on different processors.
This was crucial to allow a large HUGETLB
page region to be faulted into an address space
in parallel, using as many processors as possible.
For example, we have observed speedups
of 25x using 16 processors to touch O(100 GB)
of HUGETLB pages. (The speedup is super
linear because if you use just one processor
it has to zero many remote pages, whereas if
you use more processors, at least some of the
pages you are zeroing are local or on nearby
nodes.) Assuming we can achieve the same
kind of speedup on a 4 TB system, we would
reduce the 5,000 second time stated above to
200 seconds.
Recently, we have worked with Kenneth Chen