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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
