> David S. Miller wrote:
> > Things get free'd, but the SLAB doesn't get rid of the stuff even when
> > things reach a rediculious state. These stats are from my
> > workstation.
> >
> > in-use free
> > [ ... ]
> > buffer_head 596 96300
> > [ ... ]
> > size-128 735 43400
> > size-64 1682 44184
> >
> > Yet attempts to allocate any memory by a user process tends to fail.
> > I think try_to_free_page() should more agressively hit the SLABs.
>
> The above picture doesn't look good, but is it possible that the usage
> patterns have all of the pages poisoned by in-use objects? Any way to
> get SLAB to give some stats on potentially freeable pages?
>
> The state machine in do_try_to_free_page should stay parked in SLAB for
> as long as it's successful, so there shouldn't be any lack of attempts
> to free SLAB memory.
I just had a look at 2.1.56 and it seems to me that the state machine
stays parked to a 'reaper' as long as it succeeds for the lower priority,
first try with i=6.
The fact that kmem_cache_reap() behaviour does not use the priority (i)
(forced to 0) is highly broken in my opinion.
I missed the reason of using always priority 0 for kmem_cache_reap().
Is its reaping mechanism so broken?
My understanding of this area of the kernel is that the strategy used by
try_to_free_page() only works if the behaviour of *all* reapers is
clearly based on a priority + aging (or similar) algorithm.
When one 'reaper' does not behave so, it run the risk to break the whole
reaping system.
Looks like something you did'nt fix yet. ;)
Gerard.