zfs + uma

Jeff Roberson jroberson at jroberson.net
Tue Sep 21 06:38:55 UTC 2010


On Tue, 21 Sep 2010, Andriy Gapon wrote:

> on 19/09/2010 11:42 Andriy Gapon said the following:
>> on 19/09/2010 11:27 Jeff Roberson said the following:
>>> I don't like this because even with very large buffers you can still have high
>>> enough turnover to require per-cpu caching.  Kip specifically added UMA support
>>> to address this issue in zfs.  If you have allocations which don't require
>>> per-cpu caching and are very large why even use UMA?
>>
>> Good point.
>> Right now I am running with 4 items/bucket limit for items larger than 32KB.
>
> But I also have two counter-points actually :)
> 1. Uniformity.  E.g. you can handle all ZFS I/O buffers via the same mechanism
> regardless of buffer size.
> 2. (Open)Solaris does that for a while and it seems to suit them well.  Not
> saying that they are perfect, or the best, or an example to follow, but still
> that means quite a bit (for me).

I'm afraid there is not enough context here for me to know what 'the same 
mechanism' is or what solaris does.  Can you elaborate?

I prefer not to take the weight of specific examples too heavily when 
considering the allocator as it must handle many cases and many types of 
systems.  I believe there are cases where you want large allocations to be 
handled by per-cpu caches, regardless of whether ZFS is one such case.  If 
ZFS does not need them, then it should simply allocate directly from the 
VM.  However, I don't want to introduce some maximum constraint unless it 
can be shown that adequate behavior is not generated from some more 
adaptable algorithm.

Thanks,
Jeff

>
> -- 
> Andriy Gapon
>


More information about the freebsd-hackers mailing list