From nobody Sat Oct 08 22:34:53 2022 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MlKk83R35z4fDGD; Sat, 8 Oct 2022 22:34:56 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MlKk82zmNz3Tt4; Sat, 8 Oct 2022 22:34:56 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-oi1-x232.google.com with SMTP id w196so2941098oiw.8; Sat, 08 Oct 2022 15:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3FUONe5E7go5AIXrEXmwiDs/JlCmcHuGVthoY+q6CV8=; b=khjixnhJoCyysVZxqlkYAMJnWMaUq+RbfFjU4Tp7mkijEDNJmSDVf1bGNFxGpxGknl HaMhWrxAmc/mmWiUWJsoMykGHewiaYZf3xIvAeT1SdHfwLOE7Jdn/Uu3yKr8v3DJIjGp 7Ge7s/cV9XWtSDnjelgIRag06fsCd5mnVQZiqADjF3rDXOjDVQEwTR956BOoQNtOQkSv MjgkOj7NUsmWCDl6CpLcZ5OcSKY+4IL6uH48UJ9LmXJCNHCvpSAk9PVX/FWJB67AvBYM dUPIZXoQ0aBj2AanF33cmZtO5cIzJ/3Em0WyGmalWztXVpOyF9Ta7bFqv/21qwJM5Swk soGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3FUONe5E7go5AIXrEXmwiDs/JlCmcHuGVthoY+q6CV8=; b=ZVSZLWk+q7YKYzymr9qalSBoxO+gyC6caSHJmDmtW47Ez/XPU46VuHfWCxYpqtT/oY C209eG/3l743TkvfTjwX9L0AgYFuwAl3BuurT2QIHjd5lZnEzEZartkEWeHB+NV05ha+ 6egnnHzCwki60J9uPcbSBugYTaU02DAS9tUvD2wQwH1kIb+jyqGqAB2A9C78dWkIMIpk UyU+/l+dQqY80HQzd6u/vosKk9Wq/JZGDtL+3dzAKSmBPcI0fhMxslDHvAcEeMylcNmX KLicoiifw2cTKt9yHkCpfkr4xbt9u8GOuWInyKcx81NPV18wRn79RBFeejDKcXIlFWkf xtLg== X-Gm-Message-State: ACrzQf24h8U47xPeM1Lpn8TmhNWQ2N6M3nnJsCimMjX2OJCWnsZlPhaU LiMGvbfSA5bp2tO46bCV7sUMwGVppIkPYgTVWzRL9+8v X-Google-Smtp-Source: AMsMyM5Ihf4ZWI8Q6DBfVBUPKSNUru9c+xIbKi5j+8IYyiotfVNqhEGLh6NUJer4irlyQrZ0AVivA6d+P8tjQi04mVY= X-Received: by 2002:aca:1b0f:0:b0:353:f306:198b with SMTP id b15-20020aca1b0f000000b00353f306198bmr5776399oib.96.1665268494599; Sat, 08 Oct 2022 15:34:54 -0700 (PDT) List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 Received: by 2002:a8a:352:0:b0:474:267f:5338 with HTTP; Sat, 8 Oct 2022 15:34:53 -0700 (PDT) In-Reply-To: References: <202210081641.298GfT2F036984@gitrepo.freebsd.org> From: Mateusz Guzik Date: Sun, 9 Oct 2022 00:34:53 +0200 Message-ID: Subject: Re: git: 133935d26f20 - main - pf: atomically increment state ids To: Gleb Smirnoff Cc: Kristof Provost , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Rspamd-Queue-Id: 4MlKk82zmNz3Tt4 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 10/9/22, Gleb Smirnoff wrote: > On Sat, Oct 08, 2022 at 04:41:29PM +0000, Kristof Provost wrote: > K> commit 133935d26f20c0b9c433da9a2b32bcbe562bc2c5 > K> Author: Kristof Provost > K> AuthorDate: 2022-10-07 17:17:06 +0000 > K> Commit: Kristof Provost > K> CommitDate: 2022-10-08 16:27:29 +0000 > K> > K> pf: atomically increment state ids > K> > K> Rather than using a per-cpu state counter, and adding in the CPU id > we > K> can atomically increment the number. > K> This has the advantage of removing the assumption that the CPU ID > fits > K> in 8 bits. > K> > K> Event: Aberdeen Hackathon 2022 > K> Reviewed by: mjg > K> Differential Revision: https://reviews.freebsd.org/D36915 > > This adds an atomic operation on a single word on a state creation :( True, but patching unr64 to be fully scalable is not hard and I intend to do it later. The point from my end was to not add anything handrolled. > Previously two state creations could run in parallel without negatively > affecting each other. > That's only partially true. For one, the hash tables used (and associated locking) are not properly aligned to avoid false-sharing. But even if they were, you still have a lot of hashing conflicts and associated ping-pong from locking on lookup. And so on. I do have WIP work introduce lockless lookup here though, but there is technical debt to clean up. -- Mateusz Guzik