On 1/19/20, Warner Losh <i...@bsdimp.com> wrote: > On Sun, Jan 19, 2020, 10:05 AM Mateusz Guzik <m...@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> _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
