One of the things on the current must-fix list is:
> - Overcommit accounting gets wrong answers
>
> - underestimates reclaimable slab, gives bogus failures when
> dcache&icache are large.
More comments from Andrew:
> If the cache slab fragmentation is bad it can be hugely wrong.
> A factor of ten has been observed (rarely). Factors of two happen
> often.
...
> > But, if prune_[di]cache() will only touch those which are being
> > counted by nr_unused, how can we be more aggressive?
>
> Well, just by assuming all slab is reclaimable is one way.
>
> The problem with that is that to read slab accounting we need to do
> get_page_state(), which is too expensive to be called for every mmap()
> on big SMP.
Instead of going through get_page_state(), the following code keeps
track of entries as their space is allocated in the slab via
{con,de}structors. It _will_ overestimate the amount of reclaimable
slab but, previously, using the .nr_unused stat, this number was
underestimated and caused too many good allocations to fail. This
assumes that every dentry/inode allocated in the slab is reclaimable,
which they probably will be if we get deperate enough anyway.
and, as for the counter type being an atomic_t:
> Andrew Morton wrote:
> > Dave Hansen wrote:
> > An atomic_t might be a good idea, but I'm a bit worried that 24 bits
> > might not be enough. At 160 bytes/dentry, that's 2.5GB of dentries
> > before the counter overflows. I would imagine that we'll run out of
> > plenty of other things before we get to _that_ many dentries.
>
> The 24-bit thing is only on sparc32. I don't think 2G of dentries
> is possible on sparc32 anyway.
The attached patch is against 2.5.69-mm7.
-- Dave Hansen haveblue@us.ibm.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri May 23 2003 - 22:00:38 EST