From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) by sourceware.org (Postfix) with ESMTPS id 38FEB385E451 for ; Fri, 25 Mar 2022 15:25:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 38FEB385E451 Received: by mail-pf1-x431.google.com with SMTP id b15so6705911pfm.5 for ; Fri, 25 Mar 2022 08:25:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZGr4g6w/cRsp4zJJRCrHUaMPeli/chcfUaz/4ax/Qfw=; b=GO+JfKN3u/zBATrcFOJrN/zyaWN8PoBva7UlqQ41Ir2BtWBbnuSP3lIgl6pZy9v1Rq caDiUel6UAiI38A6KiRckI2QASHgM7Z23i4BQ/cEaoiowJXEK8zOjJLlmQub8Yx8OTQy c9Lfl0kWL/17bobG5Tqmmxtn34O/EFrA5jdSRsrhzN0PvMG6ealAu1NhVbPXxDwyQJD5 sQSHa+xoYb8g0qKcfY2UcnhPYOjbXRuoiMXV0f1LW5yMZSxh0YXbAJfoG0U+C1OISCMk 1i1PX/Wfq6wKdwg3kx0ktjwrRnBgi9ZaO1nRlOZdzNkdFEqhAN7ZciOURRe315tHUfxr 6XGg== X-Gm-Message-State: AOAM531xISQEePlzKXbihAW25NGVEWqTENPnYmc9XNShkGjFfHKPPPb3 wbwvBHfJGiElvFypTzqpMk4NdmBgT4ar3qD0z/1cDx4B X-Google-Smtp-Source: ABdhPJyM3dne0TgFz5A5s5ZjqkNvy4p0u4mB/optjtFAb8zBMgbVSe4RFVAVTZLU7ySk1an55VDsF0GUwasfsntCXT8= X-Received: by 2002:a63:6e48:0:b0:397:fb23:794f with SMTP id j69-20020a636e48000000b00397fb23794fmr126031pgc.338.1648221925121; Fri, 25 Mar 2022 08:25:25 -0700 (PDT) MIME-Version: 1.0 References: <20220325015050.2065523-1-wangyang.guo@intel.com> In-Reply-To: From: Noah Goldstein Date: Fri, 25 Mar 2022 10:25:14 -0500 Message-ID: Subject: Re: [PATCH] nptl: Add backoff mechanism to spinlock loop To: "Guo, Wangyang" Cc: GNU C Library Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2022 15:25:28 -0000 On Thu, Mar 24, 2022 at 11:32 PM Guo, Wangyang wrote: > > Noah Goldstein wrote: > > > >> + atomic_spin_nop (); > > > >> + while (--spin_count > 0); > > > >> + /* Binary exponential backoff, prepare for next loop. */ > > > >> + exp_backoff <<= 1; > > > >> } > > > >> while (LLL_MUTEX_READ_LOCK (mutex) != 0 > > > >Does this load not already prevent against the 'CAS storm'? > > > This just prevent CAS in a long held lock. > > > But if multiple threads waiting for lock at the same time, suppose > > > many of them are going to read lock state, once the lock owner release the lock at this point, those waiter threads will be convinced lock is unlocked. > > > The next step, they will all do try lock at the same time. Backoff is introduced to solve this problem. > > > > The loop isn't spinning on CAS failure which is typically where you see the poor performance. > > I get that there can still be some contention on the CAS, but shouldn't the read check limit the evict ping-ponging? > > Yes, read check can help. > But in a very high contention case, it becomes more easier to meet the above problem that needs backoff. Do we need both then? But made a quick benchmark to test this out and your right, using the lock for a tiny critical section at least (incrementing an int) see less failed CAS attempts w/ this patch and better performance :) > > > > > > >> || LLL_MUTEX_TRYLOCK (mutex) != 0); > > >