Date: Sat, 8 Dec 2018 04:49:47 +0100 From: Mateusz Guzik <mjguzik@gmail.com> To: Ian Lepore <ian@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r341682 - head/sys/sys Message-ID: <CAGudoHGUqiByb37wcbhMD3eWmxFrX5=BKMiF3bk6Ptr2WWggAg@mail.gmail.com> In-Reply-To: <1544206201.1860.288.camel@freebsd.org> References: <201812071205.wB7C5BvA038350@repo.freebsd.org> <1544206201.1860.288.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/7/18, Ian Lepore <ian@freebsd.org> wrote: > On Fri, 2018-12-07 at 12:05 +0000, Mateusz Guzik wrote: >> Author: mjg >> Date: Fri Dec 7 12:05:11 2018 >> New Revision: 341682 >> URL: https://svnweb.freebsd.org/changeset/base/341682 >> >> Log: >> unr64: use locked variant if not __LP64__ >> >> The current ifdefs are not sufficient to distinguish 32- and 64- >> bit >> variants, which results e.g. in powerpc64 not using atomics. >> >> While some 32-bit archs provide 64-bit atomics, there is no huge >> advantage >> of using them on these platforms. >> [..] > This seems like a wholly unsatisfying solution compared to how trivial > it would be to do something like have each arch's atomic.h set a symbol > to indicate whether 64-bit atomics are available. Dismissing 32-bit > arches because you don't perceive performance to be important there > doesn't seem like a valid argument. > But performance *is* improved on 32-bit architectures as well. Bitmap handling would try to very hard to reduce memory usage, which had a lot of single-threaded overhead (e.g. it allocates memory just in case and then frees it). Since 64-bit inode numbers can simply grow there is no need for any of it and memory use is 64 bit to store the variable. And that's what unr64 is doing. The main difference here is in scalability - taking a lock, bumping a variable and releasing the lock scales much worse than an atomic (which still scales poorly if heavily used). 32-bit arches don't really have enough concurrency to see a difference with this code. single-threaded this is indeed a little bit slower, but this is not running in any hot path. Fully satisfying solution would be that all architectures get 64-bit ops, even if in the worst case they end up taking a lock. Then subsystems would not have to ifdef on anything. However, there was some opposition to this proposal and I don't think this is important enough to push. -- Mateusz Guzik <mjguzik gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGudoHGUqiByb37wcbhMD3eWmxFrX5=BKMiF3bk6Ptr2WWggAg>