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 DA70BC2BD09 for ; Thu, 4 Jul 2024 03:30:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 23B096B0093; Wed, 3 Jul 2024 23:30:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1EA7A6B0095; Wed, 3 Jul 2024 23:30:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0D9A16B0096; Wed, 3 Jul 2024 23:30:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id E49AE6B0093 for ; Wed, 3 Jul 2024 23:30:56 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 82DE7C0FA8 for ; Thu, 4 Jul 2024 03:30:56 +0000 (UTC) X-FDA: 82300643712.01.442F735 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf12.hostedemail.com (Postfix) with ESMTP id 1281540009 for ; Thu, 4 Jul 2024 03:30:52 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=M0NLEBAT; spf=none (imf12.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720063842; 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:dkim-signature; bh=azW1bZ7AE900JcTjXWfygDuLk0UHRALga3aYb1TW8ps=; b=McQyF0rUeeTG/XcngsKJjzwWaoMWQixP1G5mvHVN2kAhP5J+3K+GqsePhFjc5wDZ87qi0e fouhZVNXJc8Qdpg5rF8mzsVXgIvtIbExgb9Xy0tnAWexw0bvvodZmejguOMwugE4BU6vA6 BjQI3GrUqmQSJdjh5mUpXv8UJ0mTUT4= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=M0NLEBAT; spf=none (imf12.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720063842; a=rsa-sha256; cv=none; b=8LJqe8LOv1S7b0Ug8mEavsmSOEX/utses7cYPwzyd1/UZQkg3Yhp5WzENqD3npx8z1/emw +cfRyP2fZzTYzw2jJjZJUpXPWjtdkR1cjhjhKNvoOB2q0IB+hp87IVvObE5K6Kwihj4eLc dEZvERmx2rX0MK5PvzVcDW/tsWEune4= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=azW1bZ7AE900JcTjXWfygDuLk0UHRALga3aYb1TW8ps=; b=M0NLEBATCfD9NDMZoZylBx53s5 ZGkK45FrVJM1X/FU6NQzqSr44C3Vv6mFi5uSLO5K5BSHDe34K319EI8U/PkhoNbbKzEI8Zzlp1m88 9hbpnwH+OzfDKftV4bG9DFc0SVa8BDePgZ13JoXgHi0EH9qPIhdjyAfKTjdQ9h9Q2Q1MwBPJutWcx JOwbkQ1ep3OixXBUbBE4FZRv7V0rMed4W27uPsRhTVrz4t+4uYP4kEYgO+/aE9VbhavM/Hvg/gOSs fGmpe/+2EpJH+uqayU2m1xw1S76LlG5sC37CDulU5APbE5U/HuU/8JEQevaIMEMpHKSmakJlFqPSt G60icnKw==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1sPDBK-00000002RdM-2Zog; Thu, 04 Jul 2024 03:30:50 +0000 Date: Thu, 4 Jul 2024 04:30:50 +0100 From: Matthew Wilcox To: David Hildenbrand Cc: Wei Yang , akpm@linux-foundation.org, linux-mm@kvack.org Subject: Re: [PATCH] mm/page_alloc: remove prefetchw() on freeing page to buddy system Message-ID: References: <20240702020931.7061-1-richard.weiyang@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 1281540009 X-Stat-Signature: w43kd8et8abfhd8dhbxgr33tywom7ib6 X-HE-Tag: 1720063852-144786 X-HE-Meta: U2FsdGVkX18hzYv1nXyfdcFFZHMhDPOmDgkw+P+qcrMzAjYYcb7nffhYzeV19KJmIMBjj7WI3GlnapPRQ2GEdT24jTp9h3fabp2rLn5pYTjD1ywO+Sms/kokaNG+imNYthWxWdz2a1Y208Fg5oqcZBt4GahvK7yaIAPdQuP6peqpRB/EclC1WfcSL9BDQtIa+m6uPvCMO6I2oNT6RGa/HC8F5l6UA5FLAHrqw3rxkSVqZJXGwLCusEM6zajjz1+189TaM1nEhJfkAqED2CzqrMCYugvewRSo0fHssibttKbPhaQvSUpS1ang8IHogutzUHpMlNztsKgSVlJy4zQO0GrawXay0L61HhAthZLc1K6T1uxePtYIDuzHOAZi+F/DlHK732ZKBQgoHmNTdE9zQRfRiSHUdXRgCscma5L8jNk3l/rCe11XgXqp3EVhzyaVMxRf3T8q1TsdnnjVLNV8sRKzXWInOnCKC/q7114XbnSOxL7xv4hC95ENU6MW4OJWJzrxQtDevY//Uacg/etrrID+BUx0RLZhJ4JrcF5NGwRF7zlsT4j4VWLqB3MH7heZJQ4cXvCi/KhTlk432Yt8L8GgtDdo9oEUXwLoJX7iwJcFz8/khkpclsr6tn9Siwjc7S7OeYRJqAMfwFcES2Y9zjndnGqKcz6Avkfsm2c6ymMzftD2EbDg+P/wmAA2QXHksVTk+XFs+4kHU2nomrBrEG/Xerp9P4japDvkxiMz6kRh7ar9Z7qLkz26O2e7JSW9CCt6zLJHf8N/dFvCFxkt1fS4xCtDUl/lMtqmhyQ/QBv9qYblJAUtzOntaQc75ayODFhAUDuObjhrI3eU2LmMbrNBZD1q7A1kAeB1DK3TFUmbyqvwV0Xr6gv8b9vYf/M2n6qz0Vv6F69/7kqvatLZEO8FaT9QJtO0TO87/AxOckzmnmNAJmOHliqFc6m2bgb9s1Kk1/Fedja0hRzaiHn n9+kAAd0 n1wjpNqdtzxdT9tKkENNr74rbKiKmBayWv7Ga43MRta7bUMLEKSL+KuwkJfxBe3I52UEDEDVhHArbThZWZi7Xf3bqwVy0BnBqpx2TXWiMZPXOR3fRXKppbqazoiecoZAtNmyZsyKM0Q34ib+knSQoC4EVMtQ1AJ9pjsTWRRO2DzMztDlW6dP6atcNGD0xjjIawfgy2eP+aJZr8E6Pu7muneeU6YuI3diYKYHfv9qD2pGK2qXaPytENamAb/w+7rnqPrNkpld00ZixE60UIc841X9AwxGEgwVlBeKLKfZRxGv2JEhzA2TWH1bSfQrLCcquK3Mq 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: List-Subscribe: List-Unsubscribe: On Tue, Jul 02, 2024 at 08:57:57AM +0200, David Hildenbrand wrote: > > I did 10 round bootup tests before and after this change, the data > > doesn't prove prefetchw() help speeding up bootmem freeing. The sum of > > the 10 round bootmem freeing time after prefetchw() removal even 5.2% > > faster than before. > > I suspect this is noise, though. I think it's real, though small. Each prefetchw() is an instruction, and if we can avoid issuing an instruction, we should. > Something like: > > for (;;) { > ... > if (++loop >= nr_pages) > break; > p++; > } > > > Might generate slightly better code, because we know that we execute the > loop body at least once. We use that in set_ptes(), for example. I don't think it's worth doing. Keep the loop simple and obvious. set_ptes() is different because we actually expect to execute the loop exactly once (ie most folios are small). So two compares per call to set_ptes() instead of one makes a difference. Here, we're expecting to execute this loop, what, a million times? Doing a million-and-one compares instead of a million makes no observable difference. I would like to see v2 of this patch dropped, please Andrew.