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