Date: Sat, 8 Dec 2018 11:17:53 -0800 (PST) From: "Rodney W. Grimes" <freebsd@pdx.rh.CN85.dnsmgr.net> To: Mateusz Guzik <mjguzik@gmail.com> Cc: Ian Lepore <ian@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r341682 - head/sys/sys Message-ID: <201812081917.wB8JHrJm059012@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <CAGudoHGUqiByb37wcbhMD3eWmxFrX5=BKMiF3bk6Ptr2WWggAg@mail.gmail.com>
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. All your high thread Intel and Amd CPU's can still run in 32bit with all those threads active, so you can get high concurrency on 32-bit arches. > > 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. -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201812081917.wB8JHrJm059012>