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 0011CC433F5 for ; Thu, 9 Dec 2021 10:51:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5474A6B0071; Thu, 9 Dec 2021 05:51:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4D0806B0073; Thu, 9 Dec 2021 05:51:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 372266B0074; Thu, 9 Dec 2021 05:51:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay028.a.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 2679D6B0071 for ; Thu, 9 Dec 2021 05:51:10 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id E37CA21905 for ; Thu, 9 Dec 2021 10:50:59 +0000 (UTC) X-FDA: 78897938238.02.B63621F Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf29.hostedemail.com (Postfix) with ESMTP id DE2DD120008 for ; Thu, 9 Dec 2021 10:50:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1639047058; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8WMX44FIcF1N6xF21LwWdhI92Ui/1ZtttLXrtc8/meE=; b=aYNpwcmreILLL+V+YSV2wW8kb0PKKNuoGCSejdajWcz/do7L4lY0ruxL/50kBnb9UMLl+1 5r800BdyFL9HXBC5D/JTTJbrkE8tP1u+Lxp/+PcqvDidEo55jSU6nfkKmTlHPGNKJkknYS t6Q0fh39xaWaGsGjf+0X2YAXZjHdb1E= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-581-Gd4WdHwdOpeqVuTPKxgC7A-1; Thu, 09 Dec 2021 05:50:57 -0500 X-MC-Unique: Gd4WdHwdOpeqVuTPKxgC7A-1 Received: by mail-wr1-f71.google.com with SMTP id q17-20020adff791000000b00183e734ba48so1266519wrp.8 for ; Thu, 09 Dec 2021 02:50:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=8WMX44FIcF1N6xF21LwWdhI92Ui/1ZtttLXrtc8/meE=; b=kGkI/xhr/5p/krlfovEzx/utHmTRFWVim1tYz01bjbWOkq2pf2Dsq66rtwCmBoIpKi QNsZJx1yMQmNw9PsqiqeSi3HvUi2Qv2GJhiQ3wBLtNOBSG6WA1E9e+NGZRXz7p6KXo2z mRfyOjYiTzeb6SUZdFQV9c9RShhCYt6bM2dDRLm6YPE37LiJlvPTVsiigwKrRM14ks34 3rpl/vSL0YuaRcehUsDitq2hGkQVl+OQqFtmuk7d1UYFbGHzoMKYYDSweuIkltogIxXB H86vw9CCVrWRTb2nCOgdRShjk+TNB+z/3OiF7biZub2VApZE9KTb2O9W2wODHnXaZ+9b 1n5Q== X-Gm-Message-State: AOAM532KFEiTvdNT2d4gYtDQu+TiAf2dHX7Rs6qYU7tJ93vlU0DWblpj H6hKpLoVwIUOoNTSrRObzJjmV63ZhbQkfr6+lXuErUPiixWDmPwxf+GiULavpuUsGbotL2+2j2n kZ604v4cJD5c= X-Received: by 2002:a1c:f609:: with SMTP id w9mr6017399wmc.99.1639047056432; Thu, 09 Dec 2021 02:50:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJyFtJxoZ+HMp9tXZ3J0oijd/AaehaJazoUmvUj2rmanSHM0rjneYa37IHLdZm2qxceis4Jp/g== X-Received: by 2002:a1c:f609:: with SMTP id w9mr6017358wmc.99.1639047056134; Thu, 09 Dec 2021 02:50:56 -0800 (PST) Received: from ?IPv6:2a0c:5a80:3c10:3400:3c70:6643:6e71:7eae? ([2a0c:5a80:3c10:3400:3c70:6643:6e71:7eae]) by smtp.gmail.com with ESMTPSA id c6sm11112341wmq.46.2021.12.09.02.50.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Dec 2021 02:50:55 -0800 (PST) Message-ID: Subject: Re: [PATCH v2 3/3] mm/page_alloc: Remotely drain per-cpu lists From: Nicolas Saenz Julienne To: Mel Gorman Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, frederic@kernel.org, tglx@linutronix.de, peterz@infradead.org, mtosatti@redhat.com, nilal@redhat.com, linux-rt-users@vger.kernel.org, vbabka@suse.cz, cl@linux.com, ppandit@redhat.com Date: Thu, 09 Dec 2021 11:50:53 +0100 In-Reply-To: <20211203141306.GG3301@suse.de> References: <20211103170512.2745765-1-nsaenzju@redhat.com> <20211103170512.2745765-4-nsaenzju@redhat.com> <20211203141306.GG3301@suse.de> User-Agent: Evolution 3.42.1 (3.42.1-1.fc35) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: DE2DD120008 X-Stat-Signature: e39w448e93n56pbn5qrru9yiktjbdjw1 Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=aYNpwcmr; spf=none (imf29.hostedemail.com: domain of nsaenzju@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=nsaenzju@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-HE-Tag: 1639047058-588080 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: Hi Mel, On Fri, 2021-12-03 at 14:13 +0000, Mel Gorman wrote: > On Wed, Nov 03, 2021 at 06:05:12PM +0100, Nicolas Saenz Julienne wrote: > > Some setups, notably NOHZ_FULL CPUs, are too busy to handle the per-cpu > > drain work queued by __drain_all_pages(). So introduce new a mechanism > > to remotely drain the per-cpu lists. It is made possible by remotely > > locking 'struct per_cpu_pages' new per-cpu spinlocks. A benefit of this > > new scheme is that drain operations are now migration safe. > > > > There was no observed performance degradation vs. the previous scheme. > > Both netperf and hackbench were run in parallel to triggering the > > __drain_all_pages(NULL, true) code path around ~100 times per second. > > The new scheme performs a bit better (~5%), although the important point > > here is there are no performance regressions vs. the previous mechanism. > > Per-cpu lists draining happens only in slow paths. > > > > netperf and hackbench are not great indicators of page allocator > performance as IIRC they are more slab-intensive than page allocator > intensive. I ran the series through a few benchmarks and can confirm > that there was negligible difference to netperf and hackbench. > > However, on Page Fault Test (pft in mmtests), it is noticable. On a > 2-socket cascadelake machine I get > > pft timings > 5.16.0-rc1 5.16.0-rc1 > vanilla mm-remotedrain-v2r1 > Amean system-1 27.48 ( 0.00%) 27.85 * -1.35%* > Amean system-4 28.65 ( 0.00%) 30.84 * -7.65%* > Amean system-7 28.70 ( 0.00%) 32.43 * -13.00%* > Amean system-12 30.33 ( 0.00%) 34.21 * -12.80%* > Amean system-21 37.14 ( 0.00%) 41.51 * -11.76%* > Amean system-30 36.79 ( 0.00%) 46.15 * -25.43%* > Amean system-48 58.95 ( 0.00%) 65.28 * -10.73%* > Amean system-79 111.61 ( 0.00%) 114.78 * -2.84%* > Amean system-80 113.59 ( 0.00%) 116.73 * -2.77%* > Amean elapsed-1 32.83 ( 0.00%) 33.12 * -0.88%* > Amean elapsed-4 8.60 ( 0.00%) 9.17 * -6.66%* > Amean elapsed-7 4.97 ( 0.00%) 5.53 * -11.30%* > Amean elapsed-12 3.08 ( 0.00%) 3.43 * -11.41%* > Amean elapsed-21 2.19 ( 0.00%) 2.41 * -10.06%* > Amean elapsed-30 1.73 ( 0.00%) 2.04 * -17.87%* > Amean elapsed-48 1.73 ( 0.00%) 2.03 * -17.77%* > Amean elapsed-79 1.61 ( 0.00%) 1.64 * -1.90%* > Amean elapsed-80 1.60 ( 0.00%) 1.64 * -2.50%* > > It's not specific to cascade lake, I see varying size regressions on > different Intel and AMD chips, some better and worse than this result. > The smallest regression was on a single CPU skylake machine with a 2-6% > hit. Worst was Zen1 with a 3-107% hit. > > I didn't profile it to establish why but in all cases the system CPU > usage was much higher. It *might* be because the spinlock in > per_cpu_pages crosses a new cache line and it might be cold although the > penalty seems a bit high for that to be the only factor. > > Code-wise, the patches look fine but the apparent penalty for PFT is > too severe. Thanks for taking the time to look at this. I agree the performance penalty is way too big. I'll move to an alternative approach. -- Nicolás Sáenz