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 4E63FEDE99E for ; Thu, 14 Sep 2023 09:56:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 768558D0017; Thu, 14 Sep 2023 05:56:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 718908D0001; Thu, 14 Sep 2023 05:56:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 606648D0017; Thu, 14 Sep 2023 05:56:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 4F29A8D0001 for ; Thu, 14 Sep 2023 05:56:20 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 17B7B121151 for ; Thu, 14 Sep 2023 09:56:20 +0000 (UTC) X-FDA: 81234747720.17.7EBB767 Received: from outbound-smtp58.blacknight.com (outbound-smtp58.blacknight.com [46.22.136.242]) by imf23.hostedemail.com (Postfix) with ESMTP id 419C1140003 for ; Thu, 14 Sep 2023 09:56:16 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf23.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.136.242 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694685377; a=rsa-sha256; cv=none; b=ek7qQBjBDQOgT6zw264Q2PuWD/OXwHogwBdMetSS9uXuXaWA46WNw4/3qNYRwZIZ6cXnKw Du4P6Z2egHs7y/9sDdEto+bfx6kA8INXC5ygvwZxGXQ1rr2jS/C2pPcLHit6jCfQVBK8kv 24RK8bkQoJV8bvFhZe/14U11MQgFZoE= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf23.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.136.242 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694685377; h=from:from:sender: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: in-reply-to:in-reply-to:references:references; bh=5zjHyRLlpcTdOKpMLLgT/GGfWt1NR/46qOt7w6B6FaM=; b=NRFk7pDzf9MBLf+JULVKOCG/A9qG993AZmdbbEefrpz0WvrSTK7QSC/DezI8JvrWohq9hj 4nWk3APBCONVsi4f2aGjoonWRzROiK0Na0bp28m3z39PhSAmpn1qjEGx5vdoqrVdsN3ALR SijwQ3N/ATVKnTROC5fr+hFSx0N0wXM= Received: from mail.blacknight.com (pemlinmail06.blacknight.ie [81.17.255.152]) by outbound-smtp58.blacknight.com (Postfix) with ESMTPS id 27259FABF4 for ; Thu, 14 Sep 2023 10:56:15 +0100 (IST) Received: (qmail 3257 invoked from network); 14 Sep 2023 09:56:14 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.197.19]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 14 Sep 2023 09:56:14 -0000 Date: Thu, 14 Sep 2023 10:56:08 +0100 From: Mel Gorman To: Johannes Weiner Cc: Andrew Morton , Vlastimil Babka , Miaohe Lin , Kefeng Wang , Zi Yan , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/6] mm: page_alloc: remove pcppage migratetype caching Message-ID: <20230914095608.xswhhoz2rsvbe5zu@techsingularity.net> References: <20230911195023.247694-1-hannes@cmpxchg.org> <20230911195023.247694-2-hannes@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20230911195023.247694-2-hannes@cmpxchg.org> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 419C1140003 X-Stat-Signature: hwyg493cxdkf6yo1jphrk86un1up7b5n X-Rspam-User: X-HE-Tag: 1694685376-768055 X-HE-Meta: U2FsdGVkX18cigs2C/2BYV6A7jg2exV0PVWYdmnCdPygWo9ptjw+ysLHq0zAsuhhIOlaTsUQ7KbrHXKPaSLk9EW9X1YbHa3ynMlLptHgqfg9aVwj4PoUbrEXvF9s4Q476y77RKAFJMmDTGAzVWrERXOFePJz4wuqKSM2sdLzbGOeWGqXGZBf+FkTbKofmkvUMCDBYWEx4wVaE1GQNPlHogre60qt3phl5eeUoArf93JDN7fYUWd8nHGkFdwth98l35gmQj+VnL7k/ZjpecTkyj6WDp0wGHt8hLXrLgZOJWxLmArZONqsh1nO3LPcCKrAMiaVbOgenQgGLTuzNuSyrnCi1lrmJBGIRpSB41hKvZPP7CKlIbSKEuu326VDXeos7TtXWvCoiVwKqivIOLPShV35X0RyOTLtmbdbiYBNxgoIC8usv6o9J7nO8c/NoOlOazni4qb52HpfCrKR6bKc6xxnOx5tfNxBFvnJYurHS/jIWriwWjuFDUkfx0wT4+Yn6Iem2Usg72Nergz1fb0tuV1Ra9iyZ+C4Kigah/gnhkzuaHqEtxhKz5ULHcbdg4Uzlkvv0BXnOV23pjAhRjRvbjOJs/GspWeShHzCAjBTwUAfmZB1/KQhEFfn71fkMaWdAPDSCDSlySgElQM2te/hFUkXyLcMz7rzzUYWQdPU6346IRsuQoukxfyIRlutV+Lq2+qqCssXXKJnTc4WfFQ5kEk2glUgIB85w/MF2iW5vQRWnE+Z1YjhCls9SgMNYVGSFFs1LsbKJ8y8iXfbKEZN62Rd9jT4VBqv2+gwGx91q2Nb1H2MPkCScLJ6en2aqyprWrkateDZM1iklV6KtpuN7r71uS+fIHpZi4hKdfGsbiegBH2BtRHLjmn14vjfXPbrp8YiIB0v+7injpH+4tFTcoLayTw2GQyluLFsihkLOqLr2bkiVQkCxuratedGilbn8CL1RTB2XsyM9U6WHgM AVkqJ23D SZ4jAU2sNUG+zhGpBPSGj7P5wOyoOPbus4lNJXw4rMJqGcmJg+ek0YurorZpMDYqPnqywYtZm6cZeKW9SCAEFCbfHLUFjpku58aJXGGkIOlydlfHoshIM2s+xkDAZVHSD7WC2uFwgEW4IaSsjqOPGjHbWVkvBPO5pJEZtf0ZWlewkwVu+uyO3C6+5BUxVemFE+6E8/z6aCQaU+gTwC/RU9hLQLUmgBcTmcYNua1iVkU0dUb8v560u8JgYi5VH4/Ie/2ppivjbReylq00h2ZDcBRYH7IdDyqzsOxV6gqqSwKj2999MaGpXSD2kWc9WJlIILO38ZiPMyQYXYTra0hfXkktN+g== 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 Mon, Sep 11, 2023 at 03:41:42PM -0400, Johannes Weiner wrote: > The idea behind the cache is to save get_pageblock_migratetype() > lookups during bulk freeing. A microbenchmark suggests this isn't > helping, though. The pcp migratetype can get stale, which means that > bulk freeing has an extra branch to check if the pageblock was > isolated while on the pcp. > > While the variance overlaps, the cache write and the branch seem to > make this a net negative. The following test allocates and frees > batches of 10,000 pages (~3x the pcp high marks to trigger flushing): > > Before: > 8,668.48 msec task-clock # 99.735 CPUs utilized ( +- 2.90% ) > 19 context-switches # 4.341 /sec ( +- 3.24% ) > 0 cpu-migrations # 0.000 /sec > 17,440 page-faults # 3.984 K/sec ( +- 2.90% ) > 41,758,692,473 cycles # 9.541 GHz ( +- 2.90% ) > 126,201,294,231 instructions # 5.98 insn per cycle ( +- 2.90% ) > 25,348,098,335 branches # 5.791 G/sec ( +- 2.90% ) > 33,436,921 branch-misses # 0.26% of all branches ( +- 2.90% ) > > 0.0869148 +- 0.0000302 seconds time elapsed ( +- 0.03% ) > > After: > 8,444.81 msec task-clock # 99.726 CPUs utilized ( +- 2.90% ) > 22 context-switches # 5.160 /sec ( +- 3.23% ) > 0 cpu-migrations # 0.000 /sec > 17,443 page-faults # 4.091 K/sec ( +- 2.90% ) > 40,616,738,355 cycles # 9.527 GHz ( +- 2.90% ) > 126,383,351,792 instructions # 6.16 insn per cycle ( +- 2.90% ) > 25,224,985,153 branches # 5.917 G/sec ( +- 2.90% ) > 32,236,793 branch-misses # 0.25% of all branches ( +- 2.90% ) > > 0.0846799 +- 0.0000412 seconds time elapsed ( +- 0.05% ) > > A side effect is that this also ensures that pages whose pageblock > gets stolen while on the pcplist end up on the right freelist and we > don't perform potentially type-incompatible buddy merges (or skip > merges when we shouldn't), whis is likely beneficial to long-term > fragmentation management, although the effects would be harder to > measure. Settle for simpler and faster code as justification here. > > Signed-off-by: Johannes Weiner I've no specific objection and other minor corrections have already been suggested. I don't recall specifically but I think get_pageblock_migratetype might have been called redundantly once upon a time when there were concerns about page allocator overhead for high speed network. Now that there is bulk allocation and the flow has changed significantly, it's feasible to simply avoid calling get_pageblock_migratetype unnecessarily. Acked-by: Mel Gorman -- Mel Gorman SUSE Labs