From owner-svn-src-head@freebsd.org Tue Nov 20 15:53:24 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4DEC01133B58 for ; Tue, 20 Nov 2018 15:53:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 32C5173147 for ; Tue, 20 Nov 2018 15:53:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it1-x132.google.com with SMTP id m15so4214773itl.4 for ; Tue, 20 Nov 2018 07:53:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w4vuG4uBzBVv621d+yxonx8CORiDGFCyoV+I547NDdI=; b=tI4XN7630T2j26bhXzmF3fPRBwInLyp/ODWkZUnk4AgbC3M+ZhWDKuuiWN463WqfOo ZGeLgUrAFBO6ig6wXCS5kQ6BpRCuJszKhrVXKfl8vUnca4b3l5Tft3qdkLFnInfAL7Sc M85rHqrx8pl0siBW9OsLtUrqItEZ3OP9ltoUwaxc/JxceXOwJzPu7vCDoOOoXBsUazVr 9N61IryixxqSvxzSYYD2EWzHlMbZDAx/WZXsPvYRYc2DZdKbwIXHu3+yuMzEy9QbuNzS Q2YSmss13ZcmRT4OwzhazqxcRT3LXYBNONUTVkJLUVoNRjR6UPt9jzcSOvU8BBMhM44h /JEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=w4vuG4uBzBVv621d+yxonx8CORiDGFCyoV+I547NDdI=; b=UjfTfQ5vIPUEnoPMyB0E+/epV+7Q17Q/PA6xxMlR1IeiAkTc4pnKDVYSHDbAz4/hT8 PEHS9iUr+FIipjmGK4r4kmN1bvi/0ZSy5XZVFN06OcuEpFVsycEOoXs+lBedJEJVzMqL Oya7d7pQFeWN8cq/xybQNxIhMC4Kix/YPFi5Ri7qic7//NOxnOQ5ZXWG7DdYm2WqWp+u gF8FzdqFW6Q5lPOk8H09AVlX9icgMc+LHf45GMEbAvl6SmN2ei/qq6Nvv/EiSH7P2pm3 luJccViXnc/XYRz8LPXvGBQzG0JM6clYscwYsCSbuaGWTOdGKHH2yu3dSAzCuOvDECOy My2Q== X-Gm-Message-State: AA+aEWZ1c+BeWGcUdBoMQuLHQvTW8E6I4bf2CHp4i5TQh052u6u8eKsU qzunTZ7pNJNuoDIFrg2/Igezxn6J8R3W/EZZ1b3QkQ== X-Google-Smtp-Source: AFSGD/UsxcdAgKPjBYpZPTGmDaJ0YlAK5+K8sIleh10qQTrDbOSpxq1cF3g/9mlDG2oamLBNWrn5kTqjundk+HiyjzY= X-Received: by 2002:a02:3da:: with SMTP id e87mr1935345jae.78.1542729202152; Tue, 20 Nov 2018 07:53:22 -0800 (PST) MIME-Version: 1.0 References: <201811201458.wAKEwftP033152@repo.freebsd.org> <20181120150756.GD2378@kib.kiev.ua> In-Reply-To: From: Warner Losh Date: Tue, 20 Nov 2018 08:53:11 -0700 Message-ID: Subject: Re: svn commit: r340676 - in head/sys: kern sys To: Mateusz Guzik Cc: Konstantin Belousov , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org X-Rspamd-Queue-Id: 32C5173147 X-Spamd-Result: default: False [-4.83 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[svn-src-head@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2.3.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.99)[-0.991,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-1.83)[ip: (-5.09), ipnet: 2607:f8b0::/32(-2.36), asn: 15169(-1.61), country: US(-0.09)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FREEMAIL_CC(0.00)[gmail.com] X-Rspamd-Server: mx1.freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 15:53:24 -0000 On Tue, Nov 20, 2018 at 8:28 AM Mateusz Guzik wrote: > On 11/20/18, Konstantin Belousov wrote: > > On Tue, Nov 20, 2018 at 02:58:41PM +0000, Mateusz Guzik wrote: > >> Author: mjg > >> Date: Tue Nov 20 14:58:41 2018 > >> New Revision: 340676 > >> URL: https://svnweb.freebsd.org/changeset/base/340676 > >> > >> Log: > >> Implement unr64 > >> > >> Important users of unr like tmpfs or pipes can get away with just > >> ever-increasing counters, making the overhead of managing the state > >> for 32 bit counters a pessimization. > >> > >> Change it to an atomic variable. This can be further sped up by making > >> the counts variable "allocate" ranges and store them per-cpu. > >> > >> Reviewed by: kib > >> Sponsored by: The FreeBSD Foundation > >> Differential Revision: https://reviews.freebsd.org/D18054 > >> > >> Modified: > >> head/sys/kern/subr_unit.c > >> head/sys/sys/systm.h > >> > >> Modified: head/sys/kern/subr_unit.c > >> > ============================================================================== > >> --- head/sys/kern/subr_unit.c Tue Nov 20 14:52:43 2018 > (r340675) > >> +++ head/sys/kern/subr_unit.c Tue Nov 20 14:58:41 2018 > (r340676) > >> @@ -98,6 +98,19 @@ static struct mtx unitmtx; > >> > >> MTX_SYSINIT(unit, &unitmtx, "unit# allocation", MTX_DEF); > >> > >> +#ifdef UNR64_LOCKED > >> +uint64_t > >> +alloc_unr64(struct unrhdr64 *unr64) > >> +{ > >> + uint64_t item; > >> + > >> + mtx_lock(&unitmtx); > >> + item = unr64->counter++; > >> + mtx_unlock(&unitmtx); > >> + return (item); > >> +} > >> +#endif > >> + > >> #else /* ...USERLAND */ > >> > >> #include > >> > >> Modified: head/sys/sys/systm.h > >> > ============================================================================== > >> --- head/sys/sys/systm.h Tue Nov 20 14:52:43 2018 (r340675) > >> +++ head/sys/sys/systm.h Tue Nov 20 14:58:41 2018 (r340676) > >> @@ -523,6 +523,32 @@ int alloc_unr_specific(struct unrhdr *uh, u_int > >> item); > >> int alloc_unrl(struct unrhdr *uh); > >> void free_unr(struct unrhdr *uh, u_int item); > >> > >> +#if defined(__mips__) || defined(__powerpc__) > > Please note what I asked about this #ifdefs in the review. mips > > and powerpc machine/atomic.h should define some symbol like > > __ATOMIC_NO_64_OPS and this case should be handled in less arch-explicit > > manner. > > > > Right, should have mentioned that in the commit message. > > Anyhow, mips has some degree of 64 bit ops even for 32 bits so > this becomes more iffy. In particular it does have atomic_add_64. > I don't have a good way to test mips atomics and since non-atomic > version for powerpc was needed anyway I decided not to try to > add one. > I thought the 64-bit stuff was not present in true 32-bit mips at all. You need the lld/scd instructions to do 64-bit atomics which are only available in a 64-bit environment (eg n32 or n64 execution). They throw a fatal machine error if you execute them in o32 land. And I think the proper ifdef for this is defined(mips) && !defined(__mips_n64) && !defined(__mips_n32) or something horrible like that to not pessimize 64-bit executions. > With this in place a global macro would have to explicitly indicate > lack of fetchadd, not 64 ops. So I think the current state is good > enough for now. Imo in the long run 64 bit ops should just get > emulated with a lock protected code in general manner. > We already do this for ARM. On armv4/5, there are no atomic instructions at all, so we emulate them by doing the normal operation with interrupts disabled. Since there's no MP designs from that era we support, this works out well. For most MIPS designs, this would work well too since the 32-bit mips designs we support are mostly UP (though to be fair, one can build 32-bit kernels for our 64-bit stuff, but they could cope with the lock). Warner