On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
<snip>
> kmem_cache_reap shrinks the slabs at _very_ low frequency. It's worthless to
> keep lots of dentries and icache into the slab internal queues until
> kmem_cache_reap kicks in again, if we free them such memory immediatly instead
> we'll run kmem_cache_reap later and for something more appropraite for what's
> been designed. The [id]cache shrink could release lots of memory.
I see.
Since we have code which is using GFP_BUFFER allocations to not block but
only shrink the cache (1), I've done a patch to:
- Change kmem_cache_shrink to return the number of freed pages.
- Move __GFP_IO checking from do_try_to_free_pages/refill_inactive to
{i,d}cache shrink functions (Linus already did this in his tree)
- On the {i,d}cache shrink functions, return the value of
kmem_cache_shrink() (no need of __GFP_IO for that)
There was a comment on the shrink functions about making
kmem_cache_shrink() work on a GFP_DMA/GFP_HIGHMEM basis to free only the
wanted pages by the current allocation.
GFP_DMA allocations will never reach this code (do_try_to_free_pages is
only called if __GFP_WAIT is set) and GFP_HIGHMEM pages will never be used
as SLAB obj's memory. (please correct me if I'm wrong)
Comments?
(1) Using GPF_BUFFER is wrong, but its a separate issue.
This archive was generated by hypermail 2b29 : Sat Sep 30 2000 - 21:00:13 EST