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 A7417C77B71 for ; Fri, 14 Apr 2023 23:21:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E38C3900002; Fri, 14 Apr 2023 19:21:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DE8796B007B; Fri, 14 Apr 2023 19:21:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CB006900002; Fri, 14 Apr 2023 19:21:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id BB0AA6B0078 for ; Fri, 14 Apr 2023 19:21:11 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 86F9EA046E for ; Fri, 14 Apr 2023 23:21:11 +0000 (UTC) X-FDA: 80681569542.17.59E40B1 Received: from mail-qv1-f50.google.com (mail-qv1-f50.google.com [209.85.219.50]) by imf20.hostedemail.com (Postfix) with ESMTP id 82B8F1C000D for ; Fri, 14 Apr 2023 23:21:09 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=R9xyQtVG; spf=pass (imf20.hostedemail.com: domain of opendmb@gmail.com designates 209.85.219.50 as permitted sender) smtp.mailfrom=opendmb@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681514469; 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=mNvJHKwh0D+LPXWkG2wfqhqz3XTNOZdj+I9UmzX0srw=; b=JIYyStfJAMFUfoRMJJBm4FSI1dfNslJD2bcOWNmk7IX9Z5uiumDZMKofxmLWFSpUWU0mQ3 MkNrhSHC2rgiDAzUz8qlZ4obF0grus13xtgyYxhZhjtSTCnN6pUIOQG9xpshaO81Ajh89U 6Ln0NJruPlZCFSazdcmeBCp9S2X0hz8= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=R9xyQtVG; spf=pass (imf20.hostedemail.com: domain of opendmb@gmail.com designates 209.85.219.50 as permitted sender) smtp.mailfrom=opendmb@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681514469; a=rsa-sha256; cv=none; b=QgepZJySRGbxuxn0L2mtDiRPPUxtonD1b1fhobVnQzhdxWisq3KBROK1Ye0xquJJ4lFD28 uKR8V7EicYapClsLhaj6KjneQ6uTH5tyk7O0EZy0/zRBW+bvFisxKtkeT/Sq8RfdEZAme6 69DzWep394SdWONLlpcx/Qn0xo8Wf+8= Received: by mail-qv1-f50.google.com with SMTP id dd8so7496525qvb.13 for ; Fri, 14 Apr 2023 16:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681514468; x=1684106468; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=mNvJHKwh0D+LPXWkG2wfqhqz3XTNOZdj+I9UmzX0srw=; b=R9xyQtVG78IWIhyHiFP1ZmoUUw8k0qGviTahlAQ+3KNuUamzQ6PpNRrrt6roZpZ8u6 nfuOD/3aUSw/7kjXEYnZqJ3D/ep2PBs/JFU9piDDgPs2Em72VDiYcwPOx4WjB1sZe3qD 12IEmEpY+7BXlukSPxoyVfT4HuoSLNgvkEt54SlUR+P+LHwYAd9sDU8PjvjURKeiEFl1 5CJK9zyV5ISkrYK4hvUfsgkuajXYWQ83Zeq4a8L+tExFfhgpPiW9zhwUUZAWdNuYsRca tDtDEoKsI+UUsw0YeixCQ225l9vpM1qyIMyhMmHyQda+YFmpjrEtB3yUXXYeQKUdKHKf a9JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681514468; x=1684106468; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mNvJHKwh0D+LPXWkG2wfqhqz3XTNOZdj+I9UmzX0srw=; b=AzkVSSbXrJlSKRFpCnF9lyONzsr0gnxYmpTfC4zqYI0/MbIDYeKMcKD1nBGt+YlwGG Y3CRQY4tW829UF4H/Qm4ABp8trMB3klfqk0O7KviCQvKhqUqBQ7AoOjxg0YtiDbDiVrF FITJwzQmq+BWeT7BOcYKgxU1d31y8sX3KCh+KDRHEs2T32YpDIQHb8y3cubVAEtgaZcw 8EdoInd13Wx/25sek48/JSI1Oq7b/jRhokiNN1O1w9enNy3l6YQ9ZHVSueRdR2p1Rwe6 VWgkfLeO4bJo+lD68+fOlrbReeUy1e94/mhbMCkDgzRORhC1tfmpHw6/Hy1q1zwogCEC 7X6Q== X-Gm-Message-State: AAQBX9ftIdpQcxEjf/K3igvpjmFlFf9yiq9VEh0ZZcUrMOCGzcGOoPpa jhS3btoBo1EKhBUZg66iZGo= X-Google-Smtp-Source: AKy350beqHbeqLPA9mnK3+1nIFndOzsJcH3chcnBIpFlorLKok9MS0B/CtxqwVu7LFiS86bl4MsQcA== X-Received: by 2002:a05:6214:5084:b0:5ef:6101:3282 with SMTP id kk4-20020a056214508400b005ef61013282mr1205360qvb.0.1681514468585; Fri, 14 Apr 2023 16:21:08 -0700 (PDT) Received: from [10.69.67.31] ([192.19.223.252]) by smtp.gmail.com with ESMTPSA id o22-20020a05620a22d600b007486052d731sm1568299qki.10.2023.04.14.16.20.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Apr 2023 16:21:08 -0700 (PDT) Message-ID: <085983ed-b32a-3ec6-ff4a-a340776c410b@gmail.com> Date: Fri, 14 Apr 2023 16:20:33 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.1.2 Subject: Re: [PATCH] mm: page_alloc: Skip regions with hugetlbfs pages when allocating 1G pages To: Mel Gorman , Andrew Morton Cc: Vlastimil Babka , Michal Hocko , Oscar Salvador , Yuanxi Liu , David Hildenbrand , Matthew Wilcox , Linux-MM , LKML References: <20230414141429.pwgieuwluxwez3rj@techsingularity.net> Content-Language: en-US From: Doug Berger In-Reply-To: <20230414141429.pwgieuwluxwez3rj@techsingularity.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Stat-Signature: eywm8qdt54agifi14t8msftjq9dhr8ig X-Rspam-User: X-Rspamd-Queue-Id: 82B8F1C000D X-Rspamd-Server: rspam06 X-HE-Tag: 1681514469-36694 X-HE-Meta: U2FsdGVkX1+vmdwT4hShjvgmTSYzAio6pwGCHhJ1v3KldabZzQcKOzBgNYrV6iqu+4ZQuhs4pNamd4WdLvsfTmgQ5EZkeu2rXG9eO/1KP4k+GkRqiLculozRgWiYmGVB1CyyTgSLNZJN4M+BOSv3a4ps/Nm7M4qSyD/GFDorEL8X+TtB/Jc5IWmhJrzmvpCsDFc6veMnfvSXnenrcVmNySjO1x1w3fzIooiYRSIHJffa+1Sg01aM7OSctLpYA0fBQB3LlpCXssG7xdRp4vZ98XqR/mkKRQ5YTpoIqwmE0vSUtTvJm67zoCZ9cKn9zsYwHS101JgpneLLcFWtB6YjsJBBqKhNSpUmHkajUBA22aevXfZtkr1oeq4vcNJhi6o+1IPvmAnb+N6H2oBsfgtaTCEM/heyklH3kJ6qbQS5SvuKIifoN82+WevJSKnkaXvkSCmmln0ipdk7VHtz6LOlBk2ECRkkuiH+QYhF/p11OmmtB/NzWrccNrMEFgCevV1lu++EJodluv0H4kH3Pg4HQGwZzAnwumumSo9J1K/8RlIpSbZcSrnVLIUyjMSUmPyMHhXrQWrsiy7MTJdQg5qMQkI7If8Z6CwhaTtzAKAe7y63HhBbBgp8TeicGRTNa57uxrZtG067aPE8nE/7TSLKU/2NNr926wfvePd65vY4Lf6qlvlWvT9A9uFTRjwoSfYOD2hCzpDEnY43Y0oQise/8PcZsegaJpxJ8iOJuI6TWLgN38WN4G4SxHbqLbkfHk73GBkqqPXPbvlZWmiBrjo9WyVmdswvm7hZ59n0dLXczI86KdS6HCYIPgttcO06jSV5xHd3MaBX3Ml+4rSgNTRWIGW3cJpKuWNQ2AtGwSSe4cPctnkZV7FOqOkeSlwR6bSN0WdOZZmgkBJQHbWfbg9k30kPt+i1k1HKbWpYMvIgkkc0mqkkydzEP2D6SobRyutu28NIa1bDL7DC0/FA/FJ XM5SGJbW zTHQJTFoOzcTSqSWEOpoulMW7PW8EZ/0bFti6j1g3K4+JsDkWIhY4I34ruW6Ea9KNEXXLi9qcvZZtTjf9z4WDT0lebwIXWIRM70YY/FO3WXN47rpFRJ0EUU8BtgRJAfIzXmzUKEJHJ7gkCvq40DuV5ko9CS+4LxToyeU1rumQHfES/dbkdmY3WShxo9qGVPGHUzrHIFol5uUKTHZu4PrTFjiMqh9XmkJ4EYnjPK3x8JDBnLAvWlaSF/yH+74ZgAMA/dk6ERrCDWjPu499CjeviH1ea+tJGuKbV8rUm6qsdustPSqY6jWcVvjkHBP401qZw/3aM1a1hx1lHQxIQBF/Owzi4IKUkjfvu3gromxGTFw0GcbdEp3p6BlykaKTrXLN9nWk2DPx3SelCh7PK0wzWaJVTKW1uOy7Pz+0aopwrTpf8OhgrrWCyKKdugy2jj3PLgkttrhVh/M9uT/0Up1y0BjWPc4PVcgUZe6E7tQuaMnh6pr7yGzdbLx+O9Zb6vuSsDxm0vrkFEUFyt4hnwDj3/PmRmQIQQ4OpBY0PxNRr4EFBfkLnY3eS9J+W4GfFXUiYF4q8x08cg70ncwP+vC2dsO44G+OjGnLQvEk47cRMZAs9bnV7qjL4iBAFjXAItuwvzgoQAuX906ygY6YeiNFfhVTYULYJZFE37vboIVO42xuAX/OoJ8tjJFHTdk8h+pUlHJn 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 4/14/2023 7:14 AM, 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. > A while ago I submitted this patch set that should significantly improve the chances of a 2MB Huge Page being successfully migrated: https://lore.kernel.org/linux-mm/20220921223639.1152392-1-opendmb@gmail.com/ Unfortunately, it is collecting dust and needs to be updated to support Folios, but I would be curious how it affects the performance of this test. > 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 > --- > 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; > } > I am OK with this patch too, but I could resubmit my patch with Mike's suggested variant and Folio support if anyone wants to try it instead of this approach. Regards, Doug