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 7DF23C433EF for ; Mon, 21 Feb 2022 09:43:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F34598D0002; Mon, 21 Feb 2022 04:43:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EE3D98D0001; Mon, 21 Feb 2022 04:43:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DAACD8D0002; Mon, 21 Feb 2022 04:43:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0101.hostedemail.com [216.40.44.101]) by kanga.kvack.org (Postfix) with ESMTP id C84698D0001 for ; Mon, 21 Feb 2022 04:43:32 -0500 (EST) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 7A8D7181D68A9 for ; Mon, 21 Feb 2022 09:43:32 +0000 (UTC) X-FDA: 79166299464.31.4A5FA3F Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf18.hostedemail.com (Postfix) with ESMTP id C86FF1C0004 for ; Mon, 21 Feb 2022 09:43:31 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 90CAB1F390; Mon, 21 Feb 2022 09:43:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1645436610; h=from:from:reply-to: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=u6LwIJ0VytGXZuwsUswyNAc7mSxg7aR+i+fci3dv+24=; b=Vyo4LvhNcoc4NFfJpSdgCO5QQYUd32k5m59HD2fn2quVXOwBUjZCbOMQpePjSLUGc4aFyI WD6C1pjVFdQ3ia+O4ZUiMizdKWum7Gev0KgZHErQFNo6kl5/6btTHEWwm5Id3swFh/Cks3 e0PBafErHfrigh4DKYkIh1HHduXdkzk= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1645436610; h=from:from:reply-to: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=u6LwIJ0VytGXZuwsUswyNAc7mSxg7aR+i+fci3dv+24=; b=mtuTDiuoPCSpo0Jxcx9ykNIIeTkZQ3wXduUYp8PSo9Ta6AQhL/BUIWz9C2nSex45NrU4mz tojZPCT1W+WZaHDA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 6E94E13A5C; Mon, 21 Feb 2022 09:43:30 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 9glUGsJeE2K+DAAAMHmgww (envelope-from ); Mon, 21 Feb 2022 09:43:30 +0000 Message-ID: <006330a3-8df9-dcd5-8ad6-fc23765a1266@suse.cz> Date: Mon, 21 Feb 2022 10:43:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [PATCH 1/1] mm/page_alloc: Do not prefetch buddies during bulk free Content-Language: en-US To: Mel Gorman , Andrew Morton Cc: Aaron Lu , Dave Hansen , Michal Hocko , Jesper Dangaard Brouer , LKML , Linux-MM References: <20220221094119.15282-1-mgorman@techsingularity.net> <20220221094119.15282-2-mgorman@techsingularity.net> From: Vlastimil Babka In-Reply-To: <20220221094119.15282-2-mgorman@techsingularity.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: C86FF1C0004 X-Stat-Signature: wsjrr9ef7d7u88tb59r5go98ua86zxok Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=Vyo4LvhN; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=mtuTDiuo; spf=pass (imf18.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none X-Rspam-User: X-HE-Tag: 1645436611-317364 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 2/21/22 10:41, Mel Gorman wrote: > free_pcppages_bulk() has taken two passes through the pcp lists since > commit 0a5f4e5b4562 ("mm/free_pcppages_bulk: do not hold lock when picking > pages to free") due to deferring the cost of selecting PCP lists until > the zone lock is held. > > As the list processing now takes place under the zone lock, it's less > clear that this will always benefit for two reasons. > > 1. There is a guaranteed cost to calculating the buddy which definitely > has to be calculated again. However, as the zone lock is held and > there is no deferring of buddy merging, there is no guarantee that the > prefetch will have completed when the second buddy calculation takes > place and buddies are being merged. With or without the prefetch, there > may be further stalls depending on how many pages get merged. In other > words, a stall due to merging is inevitable and at best only one stall > might be avoided at the cost of calculating the buddy location twice. > > 2. As the zone lock is held, prefetch_nr makes less sense as once > prefetch_nr expires, the cache lines of interest have already been > merged. > > The main concern is that there is a definite cost to calculating the > buddy location early for the prefetch and it is a "maybe win" depending > on whether the CPU prefetch logic and memory is fast enough. Remove the > prefetch logic on the basis that reduced instructions in a path is always > a saving where as the prefetch might save one memory stall depending on > the CPU and memory. > > In most cases, this has marginal benefit as the calculations are a small > part of the overall freeing of pages. However, it was detectable on at > least one machine. > > 5.17.0-rc3 5.17.0-rc3 > mm-highpcplimit-v2r1 mm-noprefetch-v1r1 > Min elapsed 630.00 ( 0.00%) 610.00 ( 3.17%) > Amean elapsed 639.00 ( 0.00%) 623.00 * 2.50%* > Max elapsed 660.00 ( 0.00%) 660.00 ( 0.00%) > > Suggested-by: Aaron Lu > Signed-off-by: Mel Gorman Reviewed-by: Vlastimil Babka > --- > mm/page_alloc.c | 24 ------------------------ > 1 file changed, 24 deletions(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index de9f072d23bd..2d5cc098136d 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -1432,15 +1432,6 @@ static bool bulkfree_pcp_prepare(struct page *page) > } > #endif /* CONFIG_DEBUG_VM */ > > -static inline void prefetch_buddy(struct page *page, unsigned int order) > -{ > - unsigned long pfn = page_to_pfn(page); > - unsigned long buddy_pfn = __find_buddy_pfn(pfn, order); > - struct page *buddy = page + (buddy_pfn - pfn); > - > - prefetch(buddy); > -} > - > /* > * Frees a number of pages from the PCP lists > * Assumes all pages on list are in same zone. > @@ -1453,7 +1444,6 @@ static void free_pcppages_bulk(struct zone *zone, int count, > int min_pindex = 0; > int max_pindex = NR_PCP_LISTS - 1; > unsigned int order; > - int prefetch_nr = READ_ONCE(pcp->batch); > bool isolated_pageblocks; > struct page *page; > > @@ -1508,20 +1498,6 @@ static void free_pcppages_bulk(struct zone *zone, int count, > if (bulkfree_pcp_prepare(page)) > continue; > > - /* > - * We are going to put the page back to the global > - * pool, prefetch its buddy to speed up later access > - * under zone->lock. It is believed the overhead of > - * an additional test and calculating buddy_pfn here > - * can be offset by reduced memory latency later. To > - * avoid excessive prefetching due to large count, only > - * prefetch buddy for the first pcp->batch nr of pages. > - */ > - if (prefetch_nr) { > - prefetch_buddy(page, order); > - prefetch_nr--; > - } > - > /* MIGRATE_ISOLATE page should not go to pcplists */ > VM_BUG_ON_PAGE(is_migrate_isolate(mt), page); > /* Pageblock could have been isolated meanwhile */