[lkml]   [2000]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: __GFP_IO && shrink_[d|i]cache_memory()?

On Sun, 24 Sep 2000, Ingo Molnar wrote:
> as a longer term solution, i'm wondering how hard it would be to propagate
> gfp_mask into the shrink_*() functions, and prevent recursion similarly to
> the swap-out logic? This way even GFP_BUFFER allocators could touch/free
> the dcache/icache.

Well, the gfp_mask actually _is_ propagated already, it's just that if
__GFP_IO isn't set the calls are never done.

A trivial patch would move the __GFP_IO test into the functions (no change
in behaviour), and then slowly move the test down to the proper place. We
should be able to do some SHM swapping even if __GFP_IO isn't set. For
example, I don't think shrinking the inode cache is actually illegal when
GPF_IO isn't set. In fact, it's probably only the buffer cache itself that
has to avoid recursion - the other stuff doesn't actually do any IO.


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 12:39    [W:0.210 / U:1.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site