svn commit: r269963 - head/sys/kern
delphij at delphij.net
Thu Aug 14 06:24:15 UTC 2014
-----BEGIN PGP SIGNED MESSAGE-----
On 8/13/14 10:35 PM, John-Mark Gurney wrote:
> Xin LI wrote this message on Thu, Aug 14, 2014 at 05:13 +0000:
>> Author: delphij Date: Thu Aug 14 05:13:24 2014 New Revision:
>> 269963 URL: http://svnweb.freebsd.org/changeset/base/269963
>> Log: Re-instate UMA cached backend for 4K - 64K allocations. New
>> consumers like geli(4) uses malloc(9) to allocate temporary
>> buffers that gets free'ed shortly, causing frequent TLB shootdown
>> as observed in hwpmc supported flame graph.
> Can we do even larger, like 128k for phys io sized blocks?
Sure (Actually I'm running with 128k and 256k buckets enabled on my
own storage box; with r269964 we can easily add new buckets without
actually activating them by default).
However, I'm relented to add them right now because the current
malloc(9) implementation would use the next bucket size, which is 2x
of the previous one, when the requested size is only a little bit
larger than the smaller chunk's size. In real world the larger bucket
could eat more memory than all smaller but greater than page-sized
bucket combined (the actual consumption is still small, though).
I think eventually the right way to go is to adopt more sophisticated
allocation strategy like the one used in jemalloc(3) and this
changeset is more-or-less temporary for now: I committed it mainly
because it eliminated a large portion of unwanted TLB shootdowns I
have observed with very reasonable overhead (a few megabytes of RAM).
> geli can do allocations >128k, which could be broken into two
> parts, one in the <8k sized range and the other in 128k...
Yes, this is another issue that I'd like to solve.
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
More information about the svn-src-all