Date: Tue, 18 Jun 2013 10:25:08 +0200 From: Andre Oppermann <andre@freebsd.org> To: Jeff Roberson <jeff@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r251894 - in head: lib/libmemstat sys/vm Message-ID: <51C01964.1000006@freebsd.org> In-Reply-To: <201306180450.r5I4oKoY091256@svn.freebsd.org> References: <201306180450.r5I4oKoY091256@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 18.06.2013 06:50, Jeff Roberson wrote: > Author: jeff > Date: Tue Jun 18 04:50:20 2013 > New Revision: 251894 > URL: http://svnweb.freebsd.org/changeset/base/251894 > > Log: > Refine UMA bucket allocation to reduce space consumption and improve > performance. > > - Always free to the alloc bucket if there is space. This gives LIFO > allocation order to improve hot-cache performance. This also allows > for zones with a single bucket per-cpu rather than a pair if the entire > working set fits in one bucket. > - Enable per-cpu caches of buckets. To prevent recursive bucket > allocation one bucket zone still has per-cpu caches disabled. > - Pick the initial bucket size based on a table driven maximum size > per-bucket rather than the number of items per-page. This gives > more sane initial sizes. > - Only grow the bucket size when we face contention on the zone lock, this > causes bucket sizes to grow more slowly. > - Adjust the number of items per-bucket to account for the header space. > This packs the buckets more efficiently per-page while making them > not quite powers of two. > - Eliminate the per-zone free bucket list. Always return buckets back > to the bucket zone. This ensures that as zones grow into larger > bucket sizes they eventually discard the smaller sizes. It persists > fewer buckets in the system. The locking is slightly trickier. > - Only switch buckets in zalloc, not zfree, this eliminates pathological > cases where we ping-pong between two buckets. > - Ensure that the thread that fills a new bucket gets to allocate from > it to give a better upper bound on allocation time. There used to be a problem with per CPU caches accumulating large amounts of items without freeing back to the global (or socket) pool. Do these updates to UMA change this situation and/or do you have further improvements coming up? -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51C01964.1000006>