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 AAB52C43334 for ; Wed, 29 Jun 2022 21:14:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1EB366B0071; Wed, 29 Jun 2022 17:14:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 199476B0072; Wed, 29 Jun 2022 17:14:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 061EF8E0001; Wed, 29 Jun 2022 17:14:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id E87C06B0071 for ; Wed, 29 Jun 2022 17:14:13 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C027B60DAB for ; Wed, 29 Jun 2022 21:14:13 +0000 (UTC) X-FDA: 79632526386.29.0E74D52 Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) by imf09.hostedemail.com (Postfix) with ESMTP id 643A814000B for ; Wed, 29 Jun 2022 21:14:11 +0000 (UTC) Received: by mail-pf1-f181.google.com with SMTP id 128so16203081pfv.12 for ; Wed, 29 Jun 2022 14:14:11 -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=Uh5xB0eDoFAz75o4tEx7nxB4dG+eqxB73XoQEAhQu6A=; b=crIQSuiZpHpWVDRlRRZXxBzT9JT3p3a8YFeHlfLQBrFx8IG/tKYIGd07JELJEaGSRS KuT+mw7ONtKjF604oFmyEMQ6ReoHe4i4Ka8QFTFNyTt62BgSipnUTrJyAa6QG16BCTAD ShCdyTQ0brFHFSbCVtx/Crx4cLKrJpRzfz5dm42Yqr5oFA1K2rdv4PZ1cSj0O6pyUsnK gSkXccS2D6HUAJK1lXJ9PXQAj+WEFGG+IvPFdzmkhNm7iC3CmrCYC/udS7ZKCmFiQdoB amvNhT5D0VjI9PetR3eUtS+LYOSzKnTAKp2BNOfuWmmp6Y4gQXIg2Wznw8pX89ijySk5 ALxA== 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=Uh5xB0eDoFAz75o4tEx7nxB4dG+eqxB73XoQEAhQu6A=; b=4m5f3wvAQDM2AgQOprjzv7nn8K8RfqjXk/dmTAn9x3zwdwa8jh7txuyGvogn74g2sV dzDn199qM/gAgicd9N5r4gyjheDvURPeemNl8DnmW1zzGxF85acUlSWgi/03VZ2qp8oI m+p6HlceX1mTqwDtwjbPyT1/zMf2gYumvUsnM2LfJFJz1bUc2hOkl2xE4QlQ9ogan1Uk pvYaRK7btpaO5I5LF9aP0XWtQv1rddqb2u/e9A7GJ3eTI9Kr5aM9eBI7Dqq13EW79wS/ Q1dYqJWDe7a590yLP5fY/wO+baL351KTaaxxzC0T9CJ/UG7lHhdLcrz/4Dcn+pbHll/z 1FAw== X-Gm-Message-State: AJIora/Qv1i0M1vphlvvcM9bRgUwY8Ka2MxhA9JZLo5Gf4SH2T05fKb9 v3urSeWQkrNrjIn9Z367bYXaA6fetWtufLzNRAL4Xw== X-Google-Smtp-Source: AGRyM1uYeRRrdzUbp+gG7X9xLJ2MtyiEEEaMkRn8o4AAmM6FY0HO4D109cCv1EAmZY9enbk7JlwYwjzbLJq2JUwnKNM= X-Received: by 2002:a63:5d21:0:b0:40d:d9fd:7254 with SMTP id r33-20020a635d21000000b0040dd9fd7254mr4593326pgb.353.1656537250098; Wed, 29 Jun 2022 14:14:10 -0700 (PDT) MIME-Version: 1.0 References: <20220624173656.2033256-1-jthoughton@google.com> <20220624173656.2033256-3-jthoughton@google.com> In-Reply-To: From: James Houghton Date: Wed, 29 Jun 2022 14:13:58 -0700 Message-ID: Subject: Re: [RFC PATCH 02/26] hugetlb: sort hstates in hugetlb_init_hstates To: Mike Kravetz Cc: Muchun Song , Peter Xu , David Hildenbrand , David Rientjes , Axel Rasmussen , Mina Almasry , 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=1656537251; 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=Uh5xB0eDoFAz75o4tEx7nxB4dG+eqxB73XoQEAhQu6A=; b=CvAcrHoSJ2ACILG0IHwXD5fHkWro2bui9c9eFTN7jwG502ayFryO6pGkhwON7YlGDqTUCl iFuGetZYGywvq4sO5FYCOmzzrFkHZqdNP8u0sUsTWZU1dIAbCZjs4SIxPJYEh5/kHNuAe1 lg2FiY0NAry9bepUSnfx0vcrhrHZTsI= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=crIQSuiZ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of jthoughton@google.com designates 209.85.210.181 as permitted sender) smtp.mailfrom=jthoughton@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656537251; a=rsa-sha256; cv=none; b=vV1hKgsgSj0R3U5ZA7IE2lB0bgszOjOt0DK3nbCMPWL/0VZZ04Dc7ach0xWSuH5GAxPvhm WrRhr6JkN+EsrEbfwN2g1OsNbVN1BpjVXmQDtG5WCNHX3UNaITFLSGjcy9qMtVYvdENNR+ kc63GzUFAjEYYqxmKgRxXlX1bQt1FZk= X-Rspamd-Queue-Id: 643A814000B Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=crIQSuiZ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of jthoughton@google.com designates 209.85.210.181 as permitted sender) smtp.mailfrom=jthoughton@google.com X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: f3ssbpnqm73txnc87x6ow9gfibganq8a X-HE-Tag: 1656537251-449760 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 Wed, Jun 29, 2022 at 2:06 PM Mike Kravetz wrote: > > On 06/29/22 14:39, Muchun Song wrote: > > On Tue, Jun 28, 2022 at 08:40:27AM -0700, James Houghton wrote: > > > On Mon, Jun 27, 2022 at 11:42 AM Mike Kravetz wrote: > > > > > > > > On 06/24/22 17:36, 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. > > > > > > > > > > > > > This may/will cause problems for gigantic hugetlb pages allocated at boot > > > > time. See alloc_bootmem_huge_page() where a pointer to the associated hstate > > > > is encoded within the allocated hugetlb page. These pages are added to > > > > hugetlb pools by the routine gather_bootmem_prealloc() which uses the saved > > > > hstate to add prep the gigantic page and add to the correct pool. Currently, > > > > gather_bootmem_prealloc is called after hugetlb_init_hstates. So, changing > > > > hstate order will cause errors. > > > > > > > > I do not see any reason why we could not call gather_bootmem_prealloc before > > > > hugetlb_init_hstates to avoid this issue. > > > > > > Thanks for catching this, Mike. Your suggestion certainly seems to > > > work, but it also seems kind of error prone. I'll have to look at the > > > code more closely, but maybe it would be better if I just maintained a > > > separate `struct hstate *sorted_hstate_ptrs[]`, where the original > > > > I don't think this is a good idea. If you really rely on the order of > > the initialization in this patch. The easier solution is changing > > huge_bootmem_page->hstate to huge_bootmem_page->hugepagesz. Then we > > can use size_to_hstate(huge_bootmem_page->hugepagesz) in > > gather_bootmem_prealloc(). > > > > That is a much better solution. Thanks Muchun! Indeed. Thank you, Muchun. :) > > -- > Mike Kravetz