svn commit: r251894 - in head: lib/libmemstat sys/vm

Andre Oppermann andre at freebsd.org
Tue Jun 18 08:25:26 UTC 2013


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



More information about the svn-src-head mailing list