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 29DA9C2BD09 for ; Thu, 4 Jul 2024 03:37:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 59B576B0093; Wed, 3 Jul 2024 23:37:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 54C2D6B0095; Wed, 3 Jul 2024 23:37:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 412676B0096; Wed, 3 Jul 2024 23:37:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 23F276B0093 for ; Wed, 3 Jul 2024 23:37:11 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id C9598120A02 for ; Thu, 4 Jul 2024 03:37:10 +0000 (UTC) X-FDA: 82300659420.08.096BF6B Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf10.hostedemail.com (Postfix) with ESMTP id 9E259C0016 for ; Thu, 4 Jul 2024 03:37:08 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=rGtondhU; spf=pass (imf10.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720064216; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=eOIoY6aJEi1410VPPYml86vCJCgFGNoMXYPWpuRVieg=; b=XIoWWXAheMhawBUbbelwYBz+N7LbDjhQyKqqxWKg6EEDdlNYmon0dhY2hED9wuIl+VmQBe ruQieft8cJF3TfYqrKN0QrKvqKu99S0tkGVO0NXgNChad+jshB1gJGuqSyXf9w0s88nkqP U2F1y4HfpND+jHQlECskW8jwtEUYpWM= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=rGtondhU; spf=pass (imf10.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720064216; a=rsa-sha256; cv=none; b=epDLBfHeZLr1C19dlG1wnRdA3amSKEDpCjEkMlGHVH9MwT6NLGA/g9djC/S+9U3KqfBvt0 4A4KwT1nyQvbt/cwtiZWmmZ9HWuJ4CsWIzBopKGaEgwUP5o1G58ShV3/Gdj1sCJuV5SD+K uyJn9xgIwnpFfDRN8mtCth1eBF79WBM= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 3A2AACE311D; Thu, 4 Jul 2024 03:37:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5B2E7C2BD10; Thu, 4 Jul 2024 03:37:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1720064223; bh=T2Q6Ca66DUjj6j9K0S3dXz6rcfDJ2Zbv6/je9A0eP00=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=rGtondhU3SMu/shYsOEgHx8KdB1hHplOGK4Z/qu2QWJrR0tPrEI0an/NFMXL0MxkM fxwf0WsBeZga6UOZ8CMOP5MFampKsNchdUSfnnf7mCN2HnwTXkuBfJdgBz7K2e2fQy CPChFm2ddGM2Q9RTZqzn71LQAUycqr4qbhu72pTI= Date: Wed, 3 Jul 2024 20:37:02 -0700 From: Andrew Morton To: Matthew Wilcox Cc: David Hildenbrand , Wei Yang , linux-mm@kvack.org Subject: Re: [PATCH] mm/page_alloc: remove prefetchw() on freeing page to buddy system Message-Id: <20240703203702.36ef41282c91fef8a056a63a@linux-foundation.org> In-Reply-To: References: <20240702020931.7061-1-richard.weiyang@gmail.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 9E259C0016 X-Stat-Signature: puwdzzt9qq8wsjxs348sw7hya9arawt7 X-Rspam-User: X-HE-Tag: 1720064228-257973 X-HE-Meta: U2FsdGVkX1+vkPRt504PWlqTKC3Q2OQ9Vrpv5redAe8oNT657wt//d5c+aHala4tnGiEO/Q8nMtoKqVLvS0QgE5om2lDg2geeaM1v0xvAXj91WtO0A169hHzwSEntTHTfZqYSbgxnK6IAA9cMZKHPfj+KTj1hKMIJhK1CSL26yW0UOU4T1IHT5SPXcR39wA/8rboNqDsMoODI569FipTAR8WsiWfB4F/+awQt+yIKjwxTdnq/EfEfhSADi+N4SRjKyWJZbuY6HBsgDvv9yjccjZc+NjLaCCzBnVgrIFGriuxnGAbJ7DGQY03zG53R8tW1sPP63PvfiSGebzZIPQ8ISvYe9zxmktxtdSDx8jgPIxCL//AW7wONKGlRPL2QlQvxZD6HLqx2kKPKx4fJxCeU8+U+VpB1ifHQrQXXb1PGKBMLUdcoTydvR6zQYP0oLHwPKiKWwiH5WEyjgHS35oGq4qYhS18V8j/+p1ZxpPTm4pJhObSnbNmt9jA4PdZf441wa38YDAriN/5n9X3YcuBS/q8q7aWEDQEhnwhYXkV0dFXYONQHCZ58qtNRZkyJl82cjZzj7dfBi+uVhQzbI82bcKmhnyGzkilCKxFG4FxwNzeqt26FzvozvYDNpkB+VhQBID/yIN0vEEdj/L4jHr+ZHR1+Z/LHPxRTrAjtePMg4crtGwcXstr6vZsGfQYAtAhJigYgm6ocJyLwOge+TIbWChPuyrhHw45l4xOzVCECPdD5pYnpifnevwSYyyA3i+ZbMc9cadj2IAKyUMskVdYtP37JicEA9KeDv6EGV0fnzE2GE4A5kRH1+GmAuLwXZjI9BPIi9UOPPiNWd5pru6k/53V+9eukk114CoFb24t3OAjXpQu9pwYA4qe/0ENHlscr0IrK9YWENQtPMBrz+jE6ZtzmOf0WLUwYL5wSDhALOU23cPd8fAkXFGBV5znB/OmNj5vduHwlVWRuvkzt9x 1FI2x5v7 UU4LmyDpA+UcKrH2xRGvXEIE8xsuGzhvZTaCPDiSI8oGX08sfcO9B/BvMVggFag4V+iFgLqSsD+DdrsZUX0kWhaXeGva6OsepOMM2+iFwtV0F9wWLVhmjBrIehmVnv5jmvbua2q7ar0/uDI35nkDoYk1WdqhnZphBJGetLmYbfCAtH9o1Oeh7V/a+XpqYI4sORPNMluULf23wudeX1Ab3tKVPUYehb0Retsw8Y46ZXyvrSXVQCKgQ0BJn5BguYe9Ulbu/sCZFSsKCfx18W/lFQptFvIs7+5HL804h+ltOCkQGIvlkN6frGiWeEmJBMFg/CCk6HiF4Qe82UsjO/hkVLflkJvBLqPCwkkl/64QxM4Cb4mLKKz4WFKqB5QqBpii+ACOncODD5IjoHvY= 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 Thu, 4 Jul 2024 04:30:50 +0100 Matthew Wilcox wrote: > > 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. thud. Are you supportive of v1? --- a/mm/page_alloc.c~mm-page_alloc-remove-prefetchw-on-freeing-page-to-buddy-system +++ a/mm/page_alloc.c @@ -1236,16 +1236,11 @@ void __free_pages_core(struct page *page */ if (IS_ENABLED(CONFIG_MEMORY_HOTPLUG) && unlikely(context == MEMINIT_HOTPLUG)) { - prefetchw(p); - for (loop = 0; loop < (nr_pages - 1); loop++, p++) { - prefetchw(p + 1); + for (loop = 0; loop < nr_pages; loop++, p++) { VM_WARN_ON_ONCE(PageReserved(p)); __ClearPageOffline(p); set_page_count(p, 0); } - VM_WARN_ON_ONCE(PageReserved(p)); - __ClearPageOffline(p); - set_page_count(p, 0); /* * Freeing the page with debug_pagealloc enabled will try to @@ -1255,14 +1250,10 @@ void __free_pages_core(struct page *page debug_pagealloc_map_pages(page, nr_pages); adjust_managed_page_count(page, nr_pages); } else { - prefetchw(p); - for (loop = 0; loop < (nr_pages - 1); loop++, p++) { - prefetchw(p + 1); + for (loop = 0; loop < nr_pages; loop++, p++) { __ClearPageReserved(p); set_page_count(p, 0); } - __ClearPageReserved(p); - set_page_count(p, 0); /* memblock adjusts totalram_pages() manually. */ atomic_long_add(nr_pages, &page_zone(page)->managed_pages); _