[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: filecache/swapcache questions [RFC] [RFT] [PATCH] kanoj-mm12-2.3.8Fix swapoff races
Hi,
On Mon, 28 Jun 1999 21:29:07 -0400 (EDT), Chuck Lever <cel@monkey.org>
said:
> yes, that's exactly what i did. what i can't figure out is why do the
> shrink_mmap in both places? seems like the shrink_mmap in kswapd is
> overkill if it has just been awoken by try_to_free_pages.
It hasn't necessarily. It may have been woken by networking activity.
If the memory requirements are being driven by interrupts, not
processes, then kswapd is the only chance for shrink_mmap to be called.
> stephen also mentioned "rate controlling" a trashing process, but since
> nothing in swap_out spins or sleeps, how could a process be slowed except
> by a little extra CPU time spent behind the global lock? that will slow
> everyone else down too, yes?
There are IO queue limits which will eventually stall the process. The
ll_rw_block itself one rate limiter. We also have a test in
rw_swap_page_base:
/* Don't allow too many pending pages in flight.. */
if (atomic_read(&nr_async_pages) > pager_daemon.swap_cluster)
wait = 1;
which causes the swapout to become synchronous once we have filled the
swapper queues.
> seems like try_to_free_pages ought to make a clear effort to recognize a
> process that is growing quickly and slow it down by causing it to sleep.
It does.
--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/