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.
Thanks,
Jeff
--
Alfred Perlstein
VP Software Engineering, iXsystems
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"