svn commit: r341682 - head/sys/sys

[Rodney W. Grimes]

> On 12/7/18, Ian Lepore <ian at 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 at freebsd.org