Date: Mon, 18 Nov 2013 00:41:48 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Alexander Motin <mav@freebsd.org> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Subject: Re: UMA cache back pressure Message-ID: <CAJ-VmokYgfJ1tr-99qCXosBsyTZ698oLZ2oPpkdGODjo8%2BK3LQ@mail.gmail.com> In-Reply-To: <52894C92.60905@FreeBSD.org> References: <52894C92.60905@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org> wrote: > Hi. > > 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: > http://people.freebsd.org/~mav/uma_pressure.patch > > Thank you. > > -- > Alexander Motin > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokYgfJ1tr-99qCXosBsyTZ698oLZ2oPpkdGODjo8%2BK3LQ>