On 6/18/13 5:21 PM, Jeff Roberson wrote:
On Tue, 18 Jun 2013, Alfred Perlstein wrote:
On 6/18/13 4:37 AM, Gleb Smirnoff wrote:
On Tue, Jun 18, 2013 at 10:25:08AM +0200, Andre Oppermann wrote:
A> There used to be a problem with per CPU caches accumulating large
amounts
A> of items without freeing back to the global (or socket) pool.
A>
A> Do these updates to UMA change this situation and/or do you have
further
A> improvements coming up?
This is especially a problem with ZFS, which utilizes UMA extensively.
IMHO, we need a flag for uma_zcreate() that would disable per CPU
caches, so
that certain zones (ZFS at least) would have them off.
It might be a good idea to force this flag on every zone that has
allocation >=
then the page size.
What about people running with 256GB+ ram? Do they also want the per
cpu caches off?
If you look at the new system there is a static threshold for the
initial item size required for different sized per-cpu buckets. What
might make sense is to tune this size based on available memory. For
what it's worth I looked at solaris settings and they cache roughly 4x
as much on a per-cpu basis.
The new system should tend to cache less of large and infrequent
allocations vs the old system. I can't say yet whether it is still a
problem.
I have an implementation of vmem to replace using vm_maps for
kmem_map, buffer_map, etc. which may resolve the zfs allocation
problems. I hope to get this in over the next few weeks.
That looks really exciting Jeff. Thank you.
I'm hoping we can give back some testing numbers when it goes in.
-Alfred
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
