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 8BEA5C433EF for ; Tue, 28 Jun 2022 15:35:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D0A196B0071; Tue, 28 Jun 2022 11:35:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CBA706B0072; Tue, 28 Jun 2022 11:35:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B82458E0001; Tue, 28 Jun 2022 11:35:47 -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 A9BDC6B0071 for ; Tue, 28 Jun 2022 11:35:47 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 7EB40343B5 for ; Tue, 28 Jun 2022 15:35:47 +0000 (UTC) X-FDA: 79628044734.06.4DD5AB0 Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) by imf02.hostedemail.com (Postfix) with ESMTP id A78AD80051 for ; Tue, 28 Jun 2022 15:35:46 +0000 (UTC) Received: by mail-pg1-f177.google.com with SMTP id r66so12568112pgr.2 for ; Tue, 28 Jun 2022 08:35:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7Xad2VrzPahx1am7D0ZL0QWhiKM+P04nXRGOHvrlZTs=; b=ESV4BnBikZg2lkGcaWdqk40NhArW+jR+mYCCYt3K+v6vJP69keqdbBzxxEfTLf68Cs Yib2eKchFlE+NP1dCZ30NPzNDUYfzIWaSe8PbFY5RdcjjHqgTEMuCey6K9G4swBTc6oH 43m2LBDrH1ghc0qoIMZJO0iAv4f0ZAlsyIxWKxJ+qjCsTgnljlU4MZfCnn6VGcRFf4vs 9evXz+LBdiFYR7sYI3mtH41QGLJpNK/7hX3CW9/Ktd56RIA/+n6aV5bplA+fcQW/N73y /f0jhbmHq3LEspQBSCfR3LMpDYsT2ZkdT1gboeoS9Tpp+jj4dS9mxKOncJPTUAApYJMD B97Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7Xad2VrzPahx1am7D0ZL0QWhiKM+P04nXRGOHvrlZTs=; b=63oQvZYpo8+d+0D4wD3qRO8NSesTSrBsJSndu7gP39wfGGb6Ch5JBODzrxm/OXWdzC czOIt2r0jg6lAec4OwklA8hzPfCq00lsOfL4vtACem4srmbv8ko8AstgttuDCxDD8nS9 UcoLcRFk6FVc9UUwgfUbmzPX0o+OS06t+y+v0T4CRK6oVt2w6vbp01Bok2rdgoWMRQHJ 6I0VXqZAS8teN668NaY8rP5yDvglTqfzR/y88/I+lLAWY/apuwuAqIx8KLMTA9I90/AA xUCbASCPDhR9cKEnlJIcI4mqWrlmU9974giBNe13nBx48m73F9bukeVzyKxYVJwq01aL 0FeQ== X-Gm-Message-State: AJIora/84b70GVmEM7gpZnERmEVT0/+ucrHP2p3FITCzajF2KS5AGfnu n0vzfJvwt5/jEaFF2VoH5YINewt5P/zpOGsJzIklaA== X-Google-Smtp-Source: AGRyM1tr/ZpJ7CYBKDkl50lshphA+SoJZVQyFmUIYyu6EGLo9+k3wvJQanXwT3aXGp3nVQCsHNE4PEWljlWoB3gA9dE= X-Received: by 2002:a05:6a00:2402:b0:4e1:46ca:68bd with SMTP id z2-20020a056a00240200b004e146ca68bdmr5300320pfh.70.1656430545342; Tue, 28 Jun 2022 08:35:45 -0700 (PDT) MIME-Version: 1.0 References: <20220624173656.2033256-1-jthoughton@google.com> <20220624173656.2033256-3-jthoughton@google.com> <7ec9cbbe-742a-4629-8764-90213e85ac58@nutanix.com> In-Reply-To: <7ec9cbbe-742a-4629-8764-90213e85ac58@nutanix.com> From: James Houghton Date: Tue, 28 Jun 2022 08:35:34 -0700 Message-ID: Subject: Re: [RFC PATCH 02/26] hugetlb: sort hstates in hugetlb_init_hstates To: "manish.mishra" Cc: Mike Kravetz , Muchun Song , Peter Xu , David Hildenbrand , David Rientjes , Axel Rasmussen , Mina Almasry , Jue Wang , "Dr . David Alan Gilbert" , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656430547; a=rsa-sha256; cv=none; b=F12o3F+knqvXIl9wRzm85wal9m9rqBoWR3G+ZQQvKYwdGiZpBpAWaTXyQ3+xM3oXv1baH9 0gc66h3bYFLa4vY4Dgw/Irxii42Yi+X0SXOBtgkwyZ8mAUduotQYMCA0tjiVW+MF9eHQ3j yEZn261nrx49w+wu4UnjWNwIjikDRI4= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=ESV4BnBi; spf=pass (imf02.hostedemail.com: domain of jthoughton@google.com designates 209.85.215.177 as permitted sender) smtp.mailfrom=jthoughton@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656430547; 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=7Xad2VrzPahx1am7D0ZL0QWhiKM+P04nXRGOHvrlZTs=; b=tSaZG/ejsU+q1eQlEc4f9Ned2Jg3xYnwDRvxcqBmTk3QMdekaJy3pvYl8fspbbW6b2g9+Y 8LObKBWHDDIFCfl/b1xnvtQQgb88bYk0byOQotuHd89GkOKT0aAZnfgN8mNwk0fZ1lSgPH 7JqBxZg+uNhBc3LH94ie2hPAXfuZXpY= X-Rspam-User: Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=ESV4BnBi; spf=pass (imf02.hostedemail.com: domain of jthoughton@google.com designates 209.85.215.177 as permitted sender) smtp.mailfrom=jthoughton@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam02 X-Stat-Signature: ixaaunesa8njtj95gb5dtz54s65fyhjf X-Rspamd-Queue-Id: A78AD80051 X-HE-Tag: 1656430546-626755 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 Mon, Jun 27, 2022 at 5:09 AM manish.mishra wrote: > > > On 24/06/22 11:06 pm, James Houghton wrote: > > When using HugeTLB high-granularity mapping, we need to go through the > > supported hugepage sizes in decreasing order so that we pick the largest > > size that works. Consider the case where we're faulting in a 1G hugepage > > for the first time: we want hugetlb_fault/hugetlb_no_page to map it with > > a PUD. By going through the sizes in decreasing order, we will find that > > PUD_SIZE works before finding out that PMD_SIZE or PAGE_SIZE work too. > > > > Signed-off-by: James Houghton > > --- > > mm/hugetlb.c | 40 +++++++++++++++++++++++++++++++++++++--- > > 1 file changed, 37 insertions(+), 3 deletions(-) > > > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > > index a57e1be41401..5df838d86f32 100644 > > --- a/mm/hugetlb.c > > +++ b/mm/hugetlb.c > > @@ -33,6 +33,7 @@ > > #include > > #include > > #include > > +#include > > > > #include > > #include > > @@ -48,6 +49,10 @@ > > > > int hugetlb_max_hstate __read_mostly; > > unsigned int default_hstate_idx; > > +/* > > + * After hugetlb_init_hstates is called, hstates will be sorted from largest > > + * to smallest. > > + */ > > struct hstate hstates[HUGE_MAX_HSTATE]; > > > > #ifdef CONFIG_CMA > > @@ -3144,14 +3149,43 @@ static void __init hugetlb_hstate_alloc_pages(struct hstate *h) > > kfree(node_alloc_noretry); > > } > > > > +static int compare_hstates_decreasing(const void *a, const void *b) > > +{ > > + const int shift_a = huge_page_shift((const struct hstate *)a); > > + const int shift_b = huge_page_shift((const struct hstate *)b); > > + > > + if (shift_a < shift_b) > > + return 1; > > + if (shift_a > shift_b) > > + return -1; > > + return 0; > > +} > > + > > +static void sort_hstates(void) > > +{ > > + unsigned long default_hstate_sz = huge_page_size(&default_hstate); > > + > > + /* Sort from largest to smallest. */ > > + sort(hstates, hugetlb_max_hstate, sizeof(*hstates), > > + compare_hstates_decreasing, NULL); > > + > > + /* > > + * We may have changed the location of the default hstate, so we need to > > + * update it. > > + */ > > + default_hstate_idx = hstate_index(size_to_hstate(default_hstate_sz)); > > +} > > + > > static void __init hugetlb_init_hstates(void) > > { > > struct hstate *h, *h2; > > > > - for_each_hstate(h) { > > - if (minimum_order > huge_page_order(h)) > > - minimum_order = huge_page_order(h); > > + sort_hstates(); > > > > + /* The last hstate is now the smallest. */ > > + minimum_order = huge_page_order(&hstates[hugetlb_max_hstate - 1]); > > + > > + for_each_hstate(h) { > > /* oversize hugepages were init'ed in early boot */ > > if (!hstate_is_gigantic(h)) > > hugetlb_hstate_alloc_pages(h); > > As now hstates are ordered can code which does calculation of demot_order > > can too be optimised, i mean it can be value of order of hstate at next index? > Indeed -- thanks for catching that. I'll make this optimization for the next version of this series. >