> On 12/7/18, Ian Lepore <i...@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 rgri...@freebsd.org _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
