From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by sourceware.org (Postfix) with ESMTPS id 71EC33858C2C for ; Fri, 25 Mar 2022 03:42:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 71EC33858C2C Received: by mail-pj1-x102b.google.com with SMTP id o68-20020a17090a0a4a00b001c686a48263so6558424pjo.1 for ; Thu, 24 Mar 2022 20:42:24 -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=r5HqM2VgRrat3ZcO14/yF2sdhA9DffVLb+ZilkVYmyk=; b=N/821uR/pjAgZHh0ojIyZ4xP8v+SDAWdmHjHqPnw2gc+Qb5mmEl9UHVyr3OVQedfyh NQNqChcXCfP/prV1bjuNw6D1EbGc4IYSjRGNeC6XIDMn8p6cOcY0IksdMyvGC1r3aE47 7T2JZ8d7oyaHy+oOjfqTm3Yv6f1js0ACNjLlKleTYwxwOGIlqKoxwQxPSFclRoa+s48/ acE053jsZrC7tD4cTkieLQU++h5zSJQLXgjnaPQ3SoZfIwe/6EPDcUZeEGKvDfzcjkCe bz6eh3Qy/MJqJE+ai1qYJj9vcnN3UPtJSSXD9iovsENQAGDd9Le0yWzTtKuUvfZrE09Y cjfg== X-Gm-Message-State: AOAM533wYPrOjB+3IrjaPooAIYie+c+UiDqN6bCy43eBo93YshOxKY2A n6dKNaSrQNnXUT/cIFR0DnhGUyXF92NY8annGcPyz4Qx6is= X-Google-Smtp-Source: ABdhPJxcUGNhiKlh0wKfcP3duYrwl0J960i1b7FeE5cgfkm9FEB1qJb0laE5VvzQzBClxoSN8RPNibgFgfTYwYM1sc0= X-Received: by 2002:a17:903:41d1:b0:154:76c2:f7bc with SMTP id u17-20020a17090341d100b0015476c2f7bcmr9499959ple.109.1648179743547; Thu, 24 Mar 2022 20:42:23 -0700 (PDT) MIME-Version: 1.0 References: <20220325015050.2065523-1-wangyang.guo@intel.com> In-Reply-To: From: Noah Goldstein Date: Thu, 24 Mar 2022 22:42:12 -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.6 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 03:42:25 -0000 On Thu, Mar 24, 2022 at 10:24 PM Guo, Wangyang 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? > > >> || LLL_MUTEX_TRYLOCK (mutex) != 0); >