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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
