From owner-svn-src-all@freebsd.org Sun Jan 19 20:44:15 2020 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2A7892240CC; Sun, 19 Jan 2020 20:44:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4816Gj65tBz3Cbg; Sun, 19 Jan 2020 20:44:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id 00JKhwYP090825 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 19 Jan 2020 22:44:01 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 00JKhwYP090825 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 00JKhvKA090824; Sun, 19 Jan 2020 22:43:57 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 19 Jan 2020 22:43:57 +0200 From: Konstantin Belousov To: Mateusz Guzik Cc: Warner Losh , src-committers , svn-src-all , svn-src-head@freebsd.org Subject: Re: svn commit: r356883 - head/sys/kern Message-ID: <20200119204357.GF4808@kib.kiev.ua> References: <202001191705.00JH5QRQ006755@repo.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.3 X-Spam-Checker-Version: SpamAssassin 3.4.3 (2019-12-06) on tom.home X-Rspamd-Queue-Id: 4816Gj65tBz3Cbg X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCPT_COUNT_FIVE(0.00)[5]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(0.00)[ip: (-3.05), ipnet: 2001:470::/32(-4.66), asn: 6939(-3.57), country: US(-0.05)]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2020 20:44:15 -0000 On Sun, Jan 19, 2020 at 08:51:39PM +0100, Mateusz Guzik wrote: > On 1/19/20, Warner Losh wrote: > > On Sun, Jan 19, 2020, 10:05 AM Mateusz Guzik 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.