svn commit: r356883 - head/sys/kern

[Mateusz Guzik]

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 plus maintaining coherent 64-bit counters requires extra provisions
on 32-bit architectures, which could also be avoided for numcachehv.

-- 
Mateusz Guzik <mjguzik gmail.com>