svn commit: r356883 - head/sys/kern

[Konstantin Belousov]

On Sun, Jan 19, 2020 at 08:51:39PM +0100, Mateusz Guzik wrote:
> On 1/19/20, Warner Losh <imp at bsdimp.com> wrote:
> > On Sun, Jan 19, 2020, 10:05 AM Mateusz Guzik <mjg at freebsd.org> wrote:
> >
> >> Author: mjg
> >> Date: Sun Jan 19 17:05:26 2020
> >> New Revision: 356883
> >> URL: https://svnweb.freebsd.org/changeset/base/356883
> >>
> >> Log:
> >>   cache: counter_u64_add_protected -> counter_u64_add
> >>
> >>   Fixes booting on RISC-V where it does happen to not be equivalent.
> >>
> >
> > Any reason we can't just have a counter64 API that works the same both
> > places rather than hiding what looks to my eye to be just that behind
> > ifdefs in vfs_cache.c?
> >
> 
> Both as in 32 and 64-bit?
> 
> Note the ifdef is there partially because the counter is not strictly
> 64-bit but long, meaning 32 bit on i386 and the like.
> 
> Should someone want to spend time implementing a 32-bit per-cpu counter,
> they should start with implementing a new facility for counters which are
> known to always be there (which is vast majority). They can be stored in
> per-cpu area.
> 
> Then the common case of just modifying the counter can compile to something
> fast. For example on amd64 this can be one instruction which uses %gs and
> an offset known at compilation time.
> 
> In contrast counter(9) code explicitly allocates memory, meaning all
> consumers have to deference a pointer. On top of that there is extra
> computation to find the right address. This bit could be moved elsewhere
> so that the stored address already has it in, but the fundamental differnce
> remains.
This rant is unrelated to the point of Warner' followup.

> 
> This plus maintaining coherent 64-bit counters requires extra provisions
> on 32-bit architectures, which could also be avoided for numcachehv.
If you want a facility that does long counting, then implement it, instead
of making un unrelated code of maze of non-reasonable ifdefs.

In fact, I would undertand the argument that counter(9) on all existing
32bit platforms should be just atomic_add_long(9) without any per-cpu
complications.  But again, this should be in counters code and not in
the VFS.

Please either use counter(9) for all arches, or atomic long, until
such hypothetical long counters facility is implemented.