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 68632C77B72 for ; Fri, 14 Apr 2023 14:53:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E3417280004; Fri, 14 Apr 2023 10:53:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DE468280002; Fri, 14 Apr 2023 10:53:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD2C4280004; Fri, 14 Apr 2023 10:53:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id BD3AD280002 for ; Fri, 14 Apr 2023 10:53:18 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 4814A1C5F99 for ; Fri, 14 Apr 2023 14:53:16 +0000 (UTC) X-FDA: 80680289592.08.117AAEB Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf10.hostedemail.com (Postfix) with ESMTP id 4D568C0020 for ; Fri, 14 Apr 2023 14:53:13 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=Tv+meLRM; spf=pass (imf10.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681483993; 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=Zq/oh5Lz01qwAzowZIo2vh4+wtA8CDI8Eeckvi/+KAA=; b=RI6TKiXA5cvk27afT02g5b/iIdikb6mDAufCutiJ6THYP+yEVH1kJooOFcNzveQ8VCdYHr Rn4mNIeeJQjhlkMVFr4K19wyNNBbb1SsgY/3KiU1u+1OMt2oskaMIuSgtRM/0ksXe7I6Tv b1/my6ksKa3mLjv81IuAXObp5m2aDag= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=Tv+meLRM; spf=pass (imf10.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681483993; a=rsa-sha256; cv=none; b=aJuyLRxQGfS3ZVTfnRHfR0njEgzHLX5cQ26fI5qtFGtdjV1+XjZiEKjyOQpUSctbww6g55 kuITaCvByA2EjNnWR5Yf7/OCXI85xReakjqk2ALYWqfbBQL4EQUswKZV7vt7S7/n5V0/sq 7Vw36XBhCoC1g2GptKTWOnwPhXBNgLg= 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 ECE5F1FD9D; Fri, 14 Apr 2023 14:53:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1681483991; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Zq/oh5Lz01qwAzowZIo2vh4+wtA8CDI8Eeckvi/+KAA=; b=Tv+meLRMJw9X5IGyOYJhyLLGEmE2OY0jONZQMLQlVGPNpAy5YQTVFcN0gO5NtrAfw+f9+d naVyDGAf0DW9/L43y388W+JjM1/uZnHzupoWuU2L4vo0pk1N+F3o6wAdAWpdRV91UzjNs6 qLkkE5MBi+QjW+xcx4DsNgZyMN9U/iw= 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 AE8D313498; Fri, 14 Apr 2023 14:53:10 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id KCJfKNZoOWSxMwAAMHmgww (envelope-from ); Fri, 14 Apr 2023 14:53:10 +0000 Date: Fri, 14 Apr 2023 16:53:09 +0200 From: Michal Hocko To: Mel Gorman Cc: Andrew Morton , Vlastimil Babka , Oscar Salvador , Yuanxi Liu , David Hildenbrand , Matthew Wilcox , Linux-MM , LKML Subject: Re: [PATCH] mm: page_alloc: Skip regions with hugetlbfs pages when allocating 1G pages Message-ID: References: <20230414141429.pwgieuwluxwez3rj@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230414141429.pwgieuwluxwez3rj@techsingularity.net> X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 4D568C0020 X-Stat-Signature: wuxxig6hjf78eqr5rug1j139r4j3b1y4 X-HE-Tag: 1681483993-398217 X-HE-Meta: U2FsdGVkX19HeDLoCKIxmsrHBidcd+1tziV3jZoUSd9+JwI0MaGaF/lET87w/1dmkRL1mq/DysDq7trw8nt5MWYFrs20W76mZt51LfOvy/vleww8vJbaHnCobRYaLt/CanuV68j+RLuw+KCCgtIJSbob3rQOG46Q+q8BeOKhjSOCltFzpDFDFdFgGzV4HXWbpAhOq9/7tucCsIO6JdLnI0ZIEtH0rgnZgKB+Shiw1qFU0pXO1LXJurtxD2Asi+v3pjDDOLCE7ggPCUIgOh4gg0OEYZXbARszbg+bJrQgu5sxFjG86TwWPbaHT4UB29v8dK2v+6bQ+qTNPW7CaHU9mmYWsTxHd54U9JxgqwuZdBp7u1OsELUivaxkZzDUq2ZE/qBF5RL05rG5SrFzn7ig1bJvU9GLubcyp9ZKb7Vz1JNxVzTCirQl46xHh8lvo5S0MKyxoyyzv/ZljZv07O8WRIt1/+1py9WvpqU/6a2B54N4fi/N1PBidAxQ2Q7Q6PdG2s/6xVlfHfPrG5fhqu++BZKQX2dulwATYVyiyZy2gX0HlcYeW/TZFWtAWe7bY6DrTbLRxwd2uUm9FY7Fajp8jM+fu3hqYDok01nD8Qf0CcSws98HKdSqhT4PjNAujuDAuPCXeGexUyYQ3L3OkZqsy70KH3DwjmyhS0tt6g4qFfog3Z846EgHfUtOfAKjoXZZ0GEc+KEX/Ar51CIGhX63+8fjOr+DSowMM72si3m7Wo1M76sPXK/hMoQcJezEWw0gX8swRERTsqSS/ErIg+YposkW1Y0Bgj5OUbit9GCUNyJYDDbwzDE1gnNtfSbZ17yeKoQLcB82zrNMe49fJf9Gse/qwXw7R9O90cISrFsSmABTQb8OPLa5mLJ4qwFLun6cf20KnpKLH37BBItJO8+UxC1wY45Xj3mFus+RYTIf25/P7Lf+aQdkC+RXDDBs2eFu0+0gssBvMTbBB2qYmY0 puRpaBH+ Ck0QrNE5F6aHmFmirChZoFkNL9tL96GfgbNPlvJ1p0Cg/tLGFZWSo92+udFIgeCkOTuBrpWEaScbeuA1rT/4maqzo47eGxTg2yAkz4sy3Q7mypkYLkf31H6PtwiZHw+h5e/KoSGvsIF4X0UgH8Br0EsUAebJe4NMrS2Zh6spVw70RFBmg2PAOJLWIB7ccqoO7rEiljfJJFQ4Nx/3UMc44y6TYNJ1DWp+ATQ7xL5ZDqo2jUX6YlZbgwKE+ROqMgPU6jpqHy82q6EE9Rv08jXrNFF/2GTPImTxVNCTJYgw6zanzUVqHtGZpsXsnjLDUp4NXdcb9+0aJ4YmgT9tQz9E5X5XVx5idKXN8RzNAdYbm0IwDZzIGV3dPGJJGWjZeRuj7Qh/U7fktSx/qrgpRVimu6ODjEXyKymDRxr5ewQw73t4sPKwqyktv6LO2uqL8EYyb5q2U 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 Fri 14-04-23 15:14:29, Mel Gorman wrote: > A bug was reported by Yuanxi Liu where allocating 1G pages at runtime is > taking an excessive amount of time for large amounts of memory. Further > testing allocating huge pages that the cost is linear i.e. if allocating > 1G pages in batches of 10 then the time to allocate nr_hugepages from > 10->20->30->etc increases linearly even though 10 pages are allocated at > each step. Profiles indicated that much of the time is spent checking the > validity within already existing huge pages and then attempting a migration > that fails after isolating the range, draining pages and a whole lot of > other useless work. > > Commit eb14d4eefdc4 ("mm,page_alloc: drop unnecessary checks from > pfn_range_valid_contig") removed two checks, one which ignored huge pages > for contiguous allocations as huge pages can sometimes migrate. While > there may be value on migrating a 2M page to satisfy a 1G allocation, it's > potentially expensive if the 1G allocation fails and it's pointless to > try moving a 1G page for a new 1G allocation or scan the tail pages for > valid PFNs. > > Reintroduce the PageHuge check and assume any contiguous region with > hugetlbfs pages is unsuitable for a new 1G allocation. > > The hpagealloc test allocates huge pages in batches and reports the > average latency per page over time. This test happens just after boot when > fragmentation is not an issue. Units are in milliseconds. > > hpagealloc > 6.3.0-rc6 6.3.0-rc6 6.3.0-rc6 > vanilla hugeallocrevert-v1r1 hugeallocsimple-v1r2 > Min Latency 26.42 ( 0.00%) 5.07 ( 80.82%) 18.94 ( 28.30%) > 1st-qrtle Latency 356.61 ( 0.00%) 5.34 ( 98.50%) 19.85 ( 94.43%) > 2nd-qrtle Latency 697.26 ( 0.00%) 5.47 ( 99.22%) 20.44 ( 97.07%) > 3rd-qrtle Latency 972.94 ( 0.00%) 5.50 ( 99.43%) 20.81 ( 97.86%) > Max-1 Latency 26.42 ( 0.00%) 5.07 ( 80.82%) 18.94 ( 28.30%) > Max-5 Latency 82.14 ( 0.00%) 5.11 ( 93.78%) 19.31 ( 76.49%) > Max-10 Latency 150.54 ( 0.00%) 5.20 ( 96.55%) 19.43 ( 87.09%) > Max-90 Latency 1164.45 ( 0.00%) 5.53 ( 99.52%) 20.97 ( 98.20%) > Max-95 Latency 1223.06 ( 0.00%) 5.55 ( 99.55%) 21.06 ( 98.28%) > Max-99 Latency 1278.67 ( 0.00%) 5.57 ( 99.56%) 22.56 ( 98.24%) > Max Latency 1310.90 ( 0.00%) 8.06 ( 99.39%) 26.62 ( 97.97%) > Amean Latency 678.36 ( 0.00%) 5.44 * 99.20%* 20.44 * 96.99%* > > 6.3.0-rc6 6.3.0-rc6 6.3.0-rc6 > vanilla revert-v1 hugeallocfix-v2 > Duration User 0.28 0.27 0.30 > Duration System 808.66 17.77 35.99 > Duration Elapsed 830.87 18.08 36.33 > > The vanilla kernel is poor, taking up to 1.3 second to allocate a huge page > and almost 10 minutes in total to run the test. Reverting the problematic > commit reduces it to 8ms at worst and the patch takes 26ms. This patch > fixes the main issue with skipping huge pages but leaves the page_count() > out because a page with an elevated count potentially can migrate. > > BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=217022 > Fixes: eb14d4eefdc4 ("mm,page_alloc: drop unnecessary checks from pfn_range_valid_contig") > Reported-by: Yuanxi Liu > Signed-off-by: Mel Gorman Acked-by: Michal Hocko Thanks! > --- > mm/page_alloc.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 7136c36c5d01..b47f520c3051 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -9450,6 +9450,9 @@ static bool pfn_range_valid_contig(struct zone *z, unsigned long start_pfn, > > if (PageReserved(page)) > return false; > + > + if (PageHuge(page)) > + return false; > } > return true; > } -- Michal Hocko SUSE Labs