Re: UMA cache back pressure

Hi!

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?




-adrian


On 17 November 2013 15:09, Alexander Motin <mav_at_freebsd.org> wrote:
> Hi.
>
> I've created patch, based on earlier work of avg_at_, 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:
> http://people.freebsd.org/~mav/uma_pressure.patch
>
> Thank you.
>
> --
> Alexander Motin
> _______________________________________________
> freebsd-hackers_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe_at_freebsd.org"