Your patch does three things:
* adds a couple new buckets;
* reduces some lock contention
* does the aggressive backpressure.
So, do you get any benefits from just the first one, or first two?
On 17 November 2013 15:09, Alexander Motin <m...@freebsd.org> wrote:
> I've created patch, based on earlier work of avg@, to add back pressure to
> UMA allocation caches. The problem of physical memory or KVA exhaustion
> existed there for many years and it is quite critical now for improving
> systems performance while keeping stability. Changes done in memory
> allocation last years improved situation. but haven't fixed completely. My
> patch solves remaining problems from two sides: a) reducing bucket sizes
> every time system detects low memory condition; and b) as last-resort
> mechanism for very low memory condition, it cycling over all CPUs to purge
> their per-CPU UMA caches. Benefit of this approach is in absence of any
> additional hard-coded limits on cache sizes -- they are self-tuned, based on
> load and memory pressure.
> With this change I believe it should be safe enough to enable UMA allocation
> caches in ZFS via vfs.zfs.zio.use_uma tunable (at least for amd64). I did
> many tests on machine with 24 logical cores (and as result strong allocation
> cache effects), and can say that with 40GB RAM using UMA caches, allowed by
> this change, by two times increases results of SPEC NFS benchmark on ZFS
> pool of several SSDs. To test system stability I've run the same test with
> physical memory limited to just 2GB and system successfully survived that,
> and even showed results 1.5 times better then with just last resort measures
> of b). In both cases tools/umastat no longer shows unbound UMA cache growth,
> that makes me believe in viability of this approach for longer runs.
> I would like to hear some comments about that:
> Thank you.
> Alexander Motin
> freebsd-hack...@freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"