From owner-svn-src-head@freebsd.org Tue Nov 20 15:28:47 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 153AB1132E7F; Tue, 20 Nov 2018 15:28:47 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (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 600B471E33; Tue, 20 Nov 2018 15:28:46 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-qt1-x841.google.com with SMTP id k12so389149qtf.7; Tue, 20 Nov 2018 07:28:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B4HBmYYkinLMOkjvB2w+eLrncZ9/NG2Z9ajE346LV2g=; b=l7V1921QXaBPBHG8szjTbTQT7fD4iiKkE23go6HkNzVUUCD158jJPoQHqmzPucts2H PsDUMkeUK8HltuLtNqgsFzDzralwwNba25CSU5oKtAhFj5jzIA25bajtAY52QkUF256l I+Lh3/J5pnF/xVjuft570ngjiV6qHiCfrE51QWRf2ZlT6mXjjKt9w49kEUuWDb8moARS uVozVq2uaqibrCCs5NjgCsrqIXFYk4q6jwMVT3kSO7B1H1S+wu+odk2xt0+avxfuIk/+ a6izqaKVe1/JEFkhAHjZx6KOBPvyZDzoOIKF7OyxqQoyZ+uQ8NLR57Fqj/EjtxvA7V/7 YYCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B4HBmYYkinLMOkjvB2w+eLrncZ9/NG2Z9ajE346LV2g=; b=pwk8qp2wZpVmdebjT2GZ9TjHG3PfK3vOx6LB0BH0etm17kPXqO4WKeIvuv+QGBvDuP 8mUEOS+PcdlwaK6HQlVNczsFlsqugHmmPi4cmNe5AJ7co9WgMGaa2HSfux0zZRcrmmHe fvHeQG7kM7L09UwvjS4SKTyR8M9hAWuZF/llnpOQ5IXfQxqMm15vbnHK/f9rU39gMlPe NSb3hAi0kdDbyI+rxKarsZCCJyzsQkFmqiDinChr1xQlLQrxlu3AxM0sMea3SGWNUW8P cZ0VqDJ1AkoI5WdGWYOGD77pexDCW8q1reLbu9HAGNcVQ9gO8wqRqgLHJ02DtosWtlKu eZNg== X-Gm-Message-State: AGRZ1gIQXPaAQSIQclKPY4O9FDdsLIwEGW84kJbF0EPJDCvuHy+2mxdM jmgOxhgF0IAjojL8TQtilgz1GdGpdQI8WVbZBzQ= X-Google-Smtp-Source: AJdET5fzi10XqtW2k4I61qgwwFGIZkZ30PFPGwRZ16glh2wZT6SCxt91qaTE4xGe454+w4oIMeC30PnbgwazWOiIzmc= X-Received: by 2002:ac8:46c6:: with SMTP id h6mr2289981qto.315.1542727725829; Tue, 20 Nov 2018 07:28:45 -0800 (PST) MIME-Version: 1.0 Received: by 2002:ac8:784:0:0:0:0:0 with HTTP; Tue, 20 Nov 2018 07:28:45 -0800 (PST) In-Reply-To: <20181120150756.GD2378@kib.kiev.ua> References: <201811201458.wAKEwftP033152@repo.freebsd.org> <20181120150756.GD2378@kib.kiev.ua> From: Mateusz Guzik Date: Tue, 20 Nov 2018 16:28:45 +0100 Message-ID: Subject: Re: svn commit: r340676 - in head/sys: kern sys To: Konstantin Belousov Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 600B471E33 X-Spamd-Result: default: False [-3.62 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.964,0]; R_DKIM_ALLOW(-0.20)[gmail.com]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-0.89)[-0.894,0]; TO_DN_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.60)[-0.598,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[1.4.8.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]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; IP_SCORE(-0.16)[ip: (3.29), ipnet: 2607:f8b0::/32(-2.37), asn: 15169(-1.61), country: US(-0.09)] X-Rspamd-Server: mx1.freebsd.org 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:28:47 -0000 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. 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. -- Mateusz Guzik