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 1DF37C43334 for ; Fri, 24 Jun 2022 18:51:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A620C8E0267; Fri, 24 Jun 2022 14:51:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A12358E0244; Fri, 24 Jun 2022 14:51:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8D9998E0267; Fri, 24 Jun 2022 14:51:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 7D0BD8E0244 for ; Fri, 24 Jun 2022 14:51:51 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 56136347B1 for ; Fri, 24 Jun 2022 18:51:51 +0000 (UTC) X-FDA: 79614023622.16.1CB410A Received: from mail-vk1-f173.google.com (mail-vk1-f173.google.com [209.85.221.173]) by imf27.hostedemail.com (Postfix) with ESMTP id E321A40008 for ; Fri, 24 Jun 2022 18:51:50 +0000 (UTC) Received: by mail-vk1-f173.google.com with SMTP id bb7so1608014vkb.9 for ; Fri, 24 Jun 2022 11:51:50 -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=f+KB5A9ZpXRBOGLRH7DVETVdHE7Tly7PtMb324fnHg0=; b=Bb5vqOXA7AxPyZxq8gpHAGLuTEdugkG+oQaCw8OF59I7gyQQL/F1tIh9p0B+Zw/J01 GZJyhBIIwVTeLO0wvEABar0lkjPdHp1P44B3cCUMb0sTaTMbuMKHo0Q60dIR7lsAqUe6 lLiGyEH1gkpH5LgBFecM4gCA3r3LugGWPRFTH3gy0xaERpEB4Idl/1Z46GQbMkoLaIml QwH2EVCeeaoKAtf07VekbnP511aRvslqoHt6iYZJcGh+KzFjP+02BYXXjKw2u41b5hIq dc/uEx4Kk0RbUMpD9ht7i4E26ed4S9wYIFh5DbnezOiDmLssWfaUdJDKmG/Bon0jud0g zVFA== 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=f+KB5A9ZpXRBOGLRH7DVETVdHE7Tly7PtMb324fnHg0=; b=JaXJvsM1trdApSHRY/NqI+qzFDzF6gGulRoaZkQCHfSXBS0LGAs1IEU1d1L71p03t0 fdvwjCLt4LVom/P/PXz+93XQeHyxpbWZAdcAnvM9gtKrGadrhTIIoQAMD2E8KndQGdtY 6rAYgWvenTIxZReNhfTEs7s76Zt3E5Y+pZNs3qX8fC/9c4tMVBpEEl4Woaq7jKfIdhN3 lC5n1ELz6fgK1euGKdkiECopczhZuM1z3PGEGqOVgF3TpJrrILl8+W5DbbbRcLX2ckzQ IMHpG6e6S2+ADTiBmH5EdegCB8bXmFYbqizpfmFe2XNsX8wYYHXJRXX16WfM/341OxD7 pzKw== X-Gm-Message-State: AJIora/DnGpWbiPqrGS0liNasiaFje8/ptekhcFplR2pBYuR+MouBwkO 3Vfu1FNoh78y/M5BrVf62YeQ4IXlJUt4mhTRnTyRgg== X-Google-Smtp-Source: AGRyM1uUFolFbpO1U+5VwUItji0OCRCyAC8zr093at7K7mAiNXeD25qxAOkH159LoeV4qyfU76TNovGu9OsiibZszI4= X-Received: by 2002:a05:6122:1479:b0:36c:502b:fdda with SMTP id r25-20020a056122147900b0036c502bfddamr149274vkp.14.1656096710059; Fri, 24 Jun 2022 11:51:50 -0700 (PDT) MIME-Version: 1.0 References: <20220624173656.2033256-1-jthoughton@google.com> <20220624173656.2033256-3-jthoughton@google.com> In-Reply-To: <20220624173656.2033256-3-jthoughton@google.com> From: Mina Almasry Date: Fri, 24 Jun 2022 11:51:38 -0700 Message-ID: Subject: Re: [RFC PATCH 02/26] hugetlb: sort hstates in hugetlb_init_hstates To: James Houghton Cc: Mike Kravetz , Muchun Song , Peter Xu , David Hildenbrand , David Rientjes , Axel Rasmussen , Jue Wang , Manish Mishra , "Dr . David Alan Gilbert" , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656096711; 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=f+KB5A9ZpXRBOGLRH7DVETVdHE7Tly7PtMb324fnHg0=; b=23z6b454YXmeWn/vqEFM6mYldBnJBd3A5LOgkruSyM+2CfmcbJ6yoWcmFP8DVLxfICvnJ+ bSq5WF+xNr6YwVM/8dxCnxZzucMQ1NYXcx0ga1xMPWQPbyof8f+6yXepKfCHg5cZYuU5lD Ww7eTvcYN7kuitoctGN0X3EJoRnIn0c= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Bb5vqOXA; spf=pass (imf27.hostedemail.com: domain of almasrymina@google.com designates 209.85.221.173 as permitted sender) smtp.mailfrom=almasrymina@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656096711; a=rsa-sha256; cv=none; b=qz+fgqRr0Bnsj67l20VB1HpkIDQnb42PAAg/j0DXmsAjMTjk/noC+gyTxhIPmUFDkBQHhZ o5kT0LTcANxbbcN70YlSKgfY2Yw1j/E5SZfnVZnWOnVeF2M7RCYbyRTm55IkQvfQ6O4Q++ ZyhpL+fVu/VZdTCOPiH+AxWolUJhCqA= Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Bb5vqOXA; spf=pass (imf27.hostedemail.com: domain of almasrymina@google.com designates 209.85.221.173 as permitted sender) smtp.mailfrom=almasrymina@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-Rspamd-Server: rspam06 X-Stat-Signature: sebzc89k7ygfaapkucc8qe1igi9jwegt X-Rspamd-Queue-Id: E321A40008 X-HE-Tag: 1656096710-563418 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, Jun 24, 2022 at 10:37 AM 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. > Mostly nits: Reviewed-by: Mina Almasry > 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) Maybe sort_hstates_descending(void) for extra clarity. > +{ > + unsigned long default_hstate_sz = huge_page_size(&default_hstate); > + > + /* Sort from largest to smallest. */ I'd remove this redundant comment; it's somewhat obvious what the next line does. > + 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. */ Same, given that above is sort_hstates(). > + 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); > -- > 2.37.0.rc0.161.g10f37bed90-goog >