From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 500BAC433EF for ; Tue, 10 May 2022 19:25:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230295AbiEJTZk (ORCPT ); Tue, 10 May 2022 15:25:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57732 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229533AbiEJTZg (ORCPT ); Tue, 10 May 2022 15:25:36 -0400 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B9806268E8F for ; Tue, 10 May 2022 12:25:35 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id t5so21147918edw.11 for ; Tue, 10 May 2022 12:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q02MjLOgg2Tpze+rP7gT3Qz466ICkAZt0Ry0Ipd95Jk=; b=EYGCJd6nKoa7AlCbXFoVs2wwPeK/MEzlyyIuT7RYv0vzGpEIeuOFdQINX/UX8oUQ+O zqeKwl0MK/RxV77Ect8iMtjzOqYv3i79dlLCP9x+TIdxK9JM5qr9BXQ0gfDvAS0riPkj ij+Nag5o81v4h3q5apmB7S/7VJGRJvNpxN7/E= 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=q02MjLOgg2Tpze+rP7gT3Qz466ICkAZt0Ry0Ipd95Jk=; b=aend1Rf7dghLxE97hCvA/WRBXLlI9TTg1EHny5WZGFnOxl8xlMP0yrfBN1lsK6Epnu ngkftIQOWoRroTrMRAoHj1iAywO1dNW5plvXjdj6+aYHP8yFmplYdfnovFrYHn5IG5fs /r15W0m24aA8UA3JVKnieOeYNkti0a3j1JoY02xxpKJF+CitFesBhFZ22IzfwG/eQ0Qy FsAo/ggOZSoaXERYi55h33Qdb5MTgtjXmPiAe2lZTYGOlMMLq0CEBWO0IrMD/JXMGs7k k0Eou6y9Wl0EC02I8EXBc23Z4MrvkgVHyllHmV4Mn04N8elgobOp8AONnWznRLkslLFE /gvw== X-Gm-Message-State: AOAM533n8/y+XC2OX0WqBkuBifM07pQMkreVz6yXSL1/PONfcaFLzbxe tD+x7iaZh3S3qd6J03eESuy6rS+A5wM0QtvGsrk= X-Google-Smtp-Source: ABdhPJwt2Xt8jemseEIF44yoFgfv8IWIv2MyU7Cci7/k/Zt06yRPXP42BJdIuiiQHnAVrIAVLVxi6w== X-Received: by 2002:a05:6402:2920:b0:425:d7c7:41f with SMTP id ee32-20020a056402292000b00425d7c7041fmr25222329edb.370.1652210734385; Tue, 10 May 2022 12:25:34 -0700 (PDT) Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com. [209.85.221.48]) by smtp.gmail.com with ESMTPSA id r23-20020a17090638d700b006fb6d9d25bfsm100496ejd.22.2022.05.10.12.25.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 May 2022 12:25:34 -0700 (PDT) Received: by mail-wr1-f48.google.com with SMTP id q23so33359wra.1 for ; Tue, 10 May 2022 12:25:34 -0700 (PDT) X-Received: by 2002:a5d:6d0b:0:b0:20c:4ec7:8e84 with SMTP id e11-20020a5d6d0b000000b0020c4ec78e84mr19776596wrq.281.1652210733697; Tue, 10 May 2022 12:25:33 -0700 (PDT) MIME-Version: 1.0 References: <20220420013526.GB14333@xsang-OptiPlex-9020> <7d20a9543f69523cfda280e3f5ab17d68db037ab.camel@intel.com> <37dac785a08e3a341bf05d9ee35f19718ce83d26.camel@intel.com> <56474c28-e62a-36b1-257b-9e5ffb11b0e2@redhat.com> In-Reply-To: From: Linus Torvalds Date: Tue, 10 May 2022 12:25:17 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [mm/page_alloc] f26b3fa046: netperf.Throughput_Mbps -18.0% regression To: Waiman Long Cc: "ying.huang@intel.com" , Peter Zijlstra , Will Deacon , Aaron Lu , Mel Gorman , kernel test robot , Vlastimil Babka , Dave Hansen , Jesper Dangaard Brouer , Michal Hocko , Andrew Morton , LKML , lkp@lists.01.org, kernel test robot , Feng Tang , Zhengjun Xing , fengwei.yin@intel.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 10, 2022 at 12:03 PM Linus Torvalds wrote: > > I think the PV case already basically does that - replacing the the > "store release" with a much more complex sequence. No? Looking around, the PV case is absolutely horrid, and does a cmpxchg_release() on the unlock path. Yeah, that would make the unlock *much* more expensive. And I guess that's fairly fundamental. Even if you were to avoid an explicitly atomic access - do the unlock a non-atomic write followed by a non-atomic "read pending and see if we need to something expensive", just that check would have to involve at a minimum a memory barrier, so it ends up being expensive even for the non-contended case. Linus