Date: Sun, 19 Jan 2020 20:51:39 +0100 From: Mateusz Guzik <mjguzik@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head@freebsd.org Subject: Re: svn commit: r356883 - head/sys/kern Message-ID: <CAGudoHEHNoeWywzv1ROFidnaBXAr9MhPft6jMzh7BLhXWDvFtQ@mail.gmail.com> In-Reply-To: <CANCZdfoYc6=XMv5=%2BJGsqMZQR3igiVVYBO-L04erpohe5zKxgw@mail.gmail.com> References: <202001191705.00JH5QRQ006755@repo.freebsd.org> <CANCZdfoYc6=XMv5=%2BJGsqMZQR3igiVVYBO-L04erpohe5zKxgw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/19/20, Warner Losh <imp@bsdimp.com> wrote: > On Sun, Jan 19, 2020, 10:05 AM Mateusz Guzik <mjg@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>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGudoHEHNoeWywzv1ROFidnaBXAr9MhPft6jMzh7BLhXWDvFtQ>