* 2.3.99-pre3 VM strangeness
@ 2000-03-26 19:25 Rik van Riel
0 siblings, 0 replies; only message in thread
From: Rik van Riel @ 2000-03-26 19:25 UTC (permalink / raw)
To: linux-mm
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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2000-03-26 19:25 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-03-26 19:25 2.3.99-pre3 VM strangeness Rik van Riel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox