[sent to linux-mm@kvack.org, please discuss this subject there,
only sent to linux-kernel as a status update for the people who
have posted bug reports]
Hi,
I've been playing around with 2.3.99-pre3 somewhat and I've
found that the VM subsystem seems to be working fine and
has pretty good performance. However, I've found one strange
anomaly, which results in high CPU usage by kswapd.
The problem seems to be in the current implementation of the
LRU cache, which also keeps (and needlessly ages) unfreeable
(mapped in processes) pages.
Suppose a heavily swapping program, which has 60% of physical
memory in the swap cache (not uncommon). Now we have 60% of
physical memory in the LRU queue, but only a tiny fraction of
it is freeable at any time (because we're swapping _heavily_).
In shrink_mmap(), however, we'll be scanning _all_ the pages
and immediately freeing those pages that are freeable. This
means that most of the time will be spent reshuffling a lot
of non-freeable pages. I've seen kswapd use as much as 60%
CPU, with just 800 pagefaults per second (of which just
180 hit the disk).
The correct solution will be to have only freeable pages and
buffer pages in the LRU queue. When we unmap the page in
try_to_swap_out() (and are the last PTE user) we add the page
to the back of the LRU queue.
Pages are removed from the LRU queue in two ways:
- freed when they reach the front of the queue
- reclaimed by the application from which we stole them
Buffer pages which go to the front of the queue should
have their buffers stolen and be moved to the back of the
queue when we fail in stealing all its buffers.
The size of the LRU queue can be dynamically adjusted.
If there are too many reclaims by applications, we
reduce the size of the queue, if there aren't enough of
them we probably aren't doing enough page aging and we
should increase the size of the queue.
In __get_free_pages() we can remove a page from the free
list (like we do now) or from the LRU queue when we're
low on memory. Kswapd has the task of making sure the LRU
queue is big enough (and recalculating the target size of
the LRU queue).
I'll start implementing this strategy now.
regards,
Rik
-- The Internet is not a network of computers. It is a network of people. That is its real strength.Wanna talk about the kernel? irc.openprojects.net / #kernelnewbies http://www.conectiva.com/ http://www.surriel.com/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:18 EST