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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 184DCC433F5 for ; Thu, 12 May 2022 18:56:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 466F56B0074; Thu, 12 May 2022 14:56:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 415E16B0075; Thu, 12 May 2022 14:56:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2B6B96B0078; Thu, 12 May 2022 14:56:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 1B24E6B0074 for ; Thu, 12 May 2022 14:56:19 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E0BBB318F1 for ; Thu, 12 May 2022 18:56:18 +0000 (UTC) X-FDA: 79457996436.06.DF4818E Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46]) by imf11.hostedemail.com (Postfix) with ESMTP id 436D6400B0 for ; Thu, 12 May 2022 18:56:13 +0000 (UTC) Received: by mail-ej1-f46.google.com with SMTP id gh6so12120998ejb.0 for ; Thu, 12 May 2022 11:56:18 -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=N01o2MK9zpj/dh2u/Xpb3w8n7ZmHwYIRG43aX5zXwiY=; b=VWqHFI6m05UgCKkAS3BZUIFsXQjlgwwShbmz9escP9uC5aEVY1Vps5DpBBWix+aUxd zVQZ3JYk3AK8ULZM9+xfniceVs9q7vYitugCHm+IZnF3iL8JSQl8hAtFz4apJ7E2MtG6 ffGWoPzzvS9CZHryhRuDMzgfRU98gnKDPZWUA= 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=N01o2MK9zpj/dh2u/Xpb3w8n7ZmHwYIRG43aX5zXwiY=; b=Jc+iXa2E4z0X4b0/SZBFvijh6lvOiDji/MYgIesJ4RZjSCT8vBj6VlDzl6Ev6h8rM6 IgCSJ/rdoAYTh/ga/bltKqPFwt5A5mHbccXPS+sPAM80iBvsx2oQeX8QjgktNQlFzNng 9v39Lf/6eEbLbUb0dvCYYWa5osFMOytVBbzmtN+3QSWMkHM1Id2OqbQFkWANUNUu3HCC InNNB7aH7+vbPpphWRF3vin3qS1/WZ9xzbywA6yHAdOhPx2lsBncPgsAePkv9kywF0zl ZM9eTCTnPOosTUcxBuusrio8cS9XlCrLPVZUfjnrk+MA5wljOcaFgQsxAXU6bD1HDbSB EErA== X-Gm-Message-State: AOAM530eVzG0EAFNYS7kfqvfilEzQsOV6wzIFOMpRotAXk7QSiI/TxEv 7cv25JsPssDM1f+LPIdrER+MOudVIfCKUcYzjJU= X-Google-Smtp-Source: ABdhPJwNs6qMzQbDmTCx+EbPThr7KQPoTb8iP/FvRQy5xzok4zoebxjePTNPT65fQFd5Yc7AUvjgdw== X-Received: by 2002:a17:906:a0ce:b0:6d1:cb30:3b3b with SMTP id bh14-20020a170906a0ce00b006d1cb303b3bmr1128978ejb.582.1652381776765; Thu, 12 May 2022 11:56:16 -0700 (PDT) Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com. [209.85.221.54]) by smtp.gmail.com with ESMTPSA id l7-20020aa7c307000000b0042890ee5034sm42590edq.55.2022.05.12.11.56.16 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 May 2022 11:56:16 -0700 (PDT) Received: by mail-wr1-f54.google.com with SMTP id m1so8503609wrb.8 for ; Thu, 12 May 2022 11:56:16 -0700 (PDT) X-Received: by 2002:a05:6000:2c2:b0:20c:7329:7c10 with SMTP id o2-20020a05600002c200b0020c73297c10mr865946wry.193.1652381409749; Thu, 12 May 2022 11:50:09 -0700 (PDT) MIME-Version: 1.0 References: <37dac785a08e3a341bf05d9ee35f19718ce83d26.camel@intel.com> <41c08a5371957acac5310a2e608b2e42bd231558.camel@intel.com> <20220512110634.712057e4663ecc5f697bf185@linux-foundation.org> In-Reply-To: <20220512110634.712057e4663ecc5f697bf185@linux-foundation.org> From: Linus Torvalds Date: Thu, 12 May 2022 11:49:53 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [mm/page_alloc] f26b3fa046: netperf.Throughput_Mbps -18.0% regression To: Andrew Morton Cc: Aaron Lu , "ying.huang@intel.com" , Waiman Long , Peter Zijlstra , Will Deacon , Mel Gorman , kernel test robot , Vlastimil Babka , Dave Hansen , Jesper Dangaard Brouer , Michal Hocko , LKML , lkp@lists.01.org, kernel test robot , Feng Tang , Zhengjun Xing , fengwei.yin@intel.com, Linux-MM Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 436D6400B0 X-Stat-Signature: pd13eau7wjjjy5gdy5zbncabubj5kp35 X-Rspam-User: Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=VWqHFI6m; spf=pass (imf11.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.46 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-HE-Tag: 1652381773-710314 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, May 12, 2022 at 11:06 AM Andrew Morton wrote: > > On Thu, 12 May 2022 10:42:09 -0700 Linus Torvalds wrote: > > > > In a perfect world, somebody would fix the locking to just not have as > > much contention. But assuming that isn't an option, maybe somebody > > should just look at that 'struct zone' layout a bit more. > > (hopefully adds linux-mm to cc) So I suspect the people who do re-layout would have to be the intel people who actually see the regression. Because the exact rules are quite complicated, and currently the comments about the layout don't really help much. For example, the "Read-mostly fields" comment doesn't necessarily mean that the fields in question should be kept away from the lock. Even if they are mostly read-only, if they are only read *under* the lock (because the lock still is what serializes them), then putting them in the same cacheline as the lock certainly won't hurt. And the same is actually true of things that are actively written to: if they are written to under the lock, being in the same cacheline as the lock can be a *good* thing, since then you have only one dirty cacheline. It only becomes a problem when (a) the lock is contended (so you get the bouncing from other lockers trying to get it) _and_ (b) the writing is fairly intense (so you get active bouncing back-and-forth, not just one or two bounces). And so to actually do any real analysis, you probably have to have multiple sockets, because without numbers to guide you to exactly _which_ writes are problematic, you're bound to get the heuristic wrong. And to make the issue even murkier, this whole thread is mixing up two different regressions that may not have all that much in common (ie the subject line is about one thing, but then we have that whole page_fault1 process mode results, and it's not clear that they have anything really to do with each other - just different examples of cache sensitivity). Linus