On 18.11.2013 11:45, Luigi Rizzo wrote:

On Mon, Nov 18, 2013 at 10:20 AM, Alexander Motin <m...@freebsd.org
<mailto:m...@freebsd.org>> wrote:

    On 18.11.2013 10:41, Adrian Chadd wrote:

        Your patch does three things:

        * adds a couple new buckets;

    These new buckets make bucket size self-tuning more soft and
    precise. Without them there are buckets for 1, 5, 13, 29, ... items.
    While at bigger sizes difference about 2x is fine, at smallest ones
    it is 5x and 2.6x respectively. New buckets make that line look like
    1, 3, 5, 9, 13, 29, reducing jumps between steps, making algorithm
    work softer, allocating and freeing memory in better fitting chunks.
    Otherwise there is quite a big gap between allocating 128K and
    5x128K of RAM at once.

just curious (and i do not understand whether the "1, 5 ..." are object
sizes in bytes or what),

Buckets include header (~3 pointers), plus number of item pointers. So on amd64 1, 5, 13 mean 32, 64, 128 bytes per bucket. It is not really about saving memory on buckets themselves since they are very small, comparing to stored items. We could use bigger (like 16 items) bucket zone for allocating all smaller ones, overwriting just their items limit. But more zones potentially means also lower zone lock congestion there, so why not?

would it make sense to add some instrumentation
code (a small array of counters i presume) to track the actual number
of requests for exact object sizes, and perhaps at runtime create buckets
trying to reduce waste ?

Since 10.0 buckets are also allocated from UMA cache zones, so all stats, garbage collection, etc. work by the same rules, which you can see in `vmstat -z`.

Following your reasoning there seems to be still a big gap between
some of the numbers you quote in the sequence.

Big (2x) gaps between big numbers is less important since once we got there it means we have not so much memory pressure and should not be hurt by many extra frees. At lower numbers it may be more important.

Alexander Motin
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to