[lkml]   [1998]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [2.1.130-3] Page cache DEFINATELY too persistant... feature?
On 27 Nov 1998, Zlatko Calusic wrote:
> "Stephen C. Tweedie" <> writes:
> > The real problem seems to be that shrink_mmap() can fail for two
> > completely separate reasons. First of all, we might fail to find a
> > free page because all of the cache pages we find are recently
> > referenced. Secondly, we might fail to find a cache page at all.
> Yesterday, I was trying to understand the very same problem you're
> speaking of. Sometimes kswapd decides to swapout lots of things,
> sometimes not.
> I applied your patch, but it didn't solve the problem.
> To be honest, things are now even slightly worse. :(

The 'fix' is to lower the borrow percentages for both
the buffer cache and the page cache. If we don't do
that (or abolish the percentages completely) kswapd
doesn't have an incentive to switch from a succesful
round of swap_out() -- which btw doesn't free any
actual memory so kswapd just continues doing that --
to shrink_mmap().

Another thing we might want to try is inserting the
following test in do_try_to_free_page():

if (atomic_read(&nr_async_pages) >= pager_daemon.swap_cluster)
state = 0;

This will switch kswapd to shrink_mmap() when we have enough
pages queued for efficient swap I/O. Of course this 'fix'
decreases swap throughput so we might want to think up something
more clever instead...


Rik -- now completely used to dvorak kbd layout...
| Linux memory management tour guide. |
| Scouting Vries cubscout leader. |

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:45    [W:0.129 / U:3.296 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site