Still getting kmem exhausted panic

Andriy Gapon avg at icyb.net.ua
Tue Sep 28 22:22:59 UTC 2010


on 29/09/2010 01:01 Ben Kelly said the following:
> Thanks.  Yea, there is a lot of aggressive tuning there.  In particular, the
> slow growth algorithm is somewhat dubious.  What I found, though, was that
> the fragmentation jumped whenever the arc was reduced in size, so it was an
> attempt to make the size slowly approach peak load without overshooting.
> 
> A better long term solution would probably be to enhance UMA to support
> custom slab sizes on a zone-by-zone basis.  That way all zfs/arc allocations
> can use slabs of 128k (at a memory efficiency penalty of course).  I
> prototyped this with a dumbed down block pool allocator at one point and was
> able to avoid most, if not all, of the fragmentation.  Adding the support to
> UMA seemed non-trivial, though.

BTW, have you seen my posts about UMA and ZFS on hackers@ ?
I found it advantageous to use UMA for ZFS I/O buffers, but only after reducing
size of per-CPU caches for the zones with large-sized items.
I further modified the code in my local tree to completely disable per-CPU
caches for items > 32KB.

-- 
Andriy Gapon


More information about the freebsd-stable mailing list