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