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 A5842C433EF for ; Tue, 19 Apr 2022 06:24:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C1F1A8D004B; Tue, 19 Apr 2022 02:24:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BCEC98D0047; Tue, 19 Apr 2022 02:24:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A71DB8D004B; Tue, 19 Apr 2022 02:24:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 980F18D0047 for ; Tue, 19 Apr 2022 02:24:03 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 65059612B2 for ; Tue, 19 Apr 2022 06:24:03 +0000 (UTC) X-FDA: 79372638366.20.A086508 Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) by imf17.hostedemail.com (Postfix) with ESMTP id 3169E4000A for ; Tue, 19 Apr 2022 06:24:01 +0000 (UTC) Received: by mail-pj1-f52.google.com with SMTP id j8-20020a17090a060800b001cd4fb60dccso1376901pjj.2 for ; Mon, 18 Apr 2022 23:24:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=HcOm58iTm0VxH3c2zlAplu3ZQMbf9aIp/+cejmaeHyI=; b=Dnyhh0NtgNw4iqSxEAh8EFGl3vpQRI+53TPg03N/0kNEMI4lxmK+gHgYXFksRh2lJ+ R9ZeebLpM/29twY5Dk273cwcDTP6bXpK2m8TMY6LY2CQakgcELYbZevqxvqI6c1bYVlQ R2G62Cq2ZLnZ4URP++fpZCHVMxHfftsY4wuJUCDqmIUpI3I86QvvppKDc6OwquHsRjh+ 10+sd+aud+oxLTKqw3H6EeJtj4tjw3296T7LZkE6YPHur22ET0HSE1+DQZgBWecrv2z8 0dn/wdDCIShvwFg7hxsnyt22mUxouahIXdxt0P4Q0igA+IHsVYCYFNH4ouw9voDf9LZt 17MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=HcOm58iTm0VxH3c2zlAplu3ZQMbf9aIp/+cejmaeHyI=; b=rnzJDft3Vemr+EASQVqs3+/uEoepJOqPdZMk3LPXMH9ICpGwugrl5UV8NvW71ueQ2T PbkPj8qDUMXhjBJrhftjOFZ7bqH7VqRiG1V2tbbuxPorqNbA48AFML3HjndiAl0Pq6Ej 1SWV29JhMfhmJdtdQoLweZvpL071rjKHKvRnPnZ9cz/dW+EGHDWCrQYIB0HavvmZqwDi JBF7HtwXeh7LOtheSFBmlYgdnqlupJ5y5IXpn4E00u92yFA2khv+3jmZjHFlEwEX+iQl 7zRqID6/CJFUdnnvk/eLFz4h51pzeqlFq97FXbK/slmUpYstB3M9Kj2GntIuORjLs7Jl UmFQ== X-Gm-Message-State: AOAM532SBP7VIs93ery2mN0eC0LzCEWNPqvueOsKXk/8/yCD2uEAU/si IwhlmjKTvQRoHIxkD2eey5DWOA== X-Google-Smtp-Source: ABdhPJzuga1jVkb36XA3IQbXLRjDomJ9OVFusCa5i5OWfpyfmH7OiSRCHdD4WQbuooR9m4UrxEc9IQ== X-Received: by 2002:a17:90b:255:b0:1cf:39e7:a7aa with SMTP id fz21-20020a17090b025500b001cf39e7a7aamr16924592pjb.137.1650349441107; Mon, 18 Apr 2022 23:24:01 -0700 (PDT) Received: from localhost ([139.177.225.229]) by smtp.gmail.com with ESMTPSA id 35-20020a631763000000b0039d93f8c2f0sm14874164pgx.24.2022.04.18.23.24.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Apr 2022 23:24:00 -0700 (PDT) Date: Tue, 19 Apr 2022 14:23:56 +0800 From: Muchun Song To: Andrew Morton Cc: corbet@lwn.net, mike.kravetz@oracle.com, mcgrof@kernel.org, keescook@chromium.org, yzaikin@google.com, osalvador@suse.de, david@redhat.com, masahiroy@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, duanxiongchun@bytedance.com, smuchun@gmail.com Subject: Re: [PATCH v8 1/4] mm: hugetlb_vmemmap: introduce CONFIG_HUGETLB_PAGE_HAS_OPTIMIZE_VMEMMAP Message-ID: References: <20220413144748.84106-1-songmuchun@bytedance.com> <20220413144748.84106-2-songmuchun@bytedance.com> <20220413120804.3570dc230a958f4923e3f3c3@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 3169E4000A X-Stat-Signature: 3yug6n8n4kj9fe3moj86zndabhjtjxgq Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=Dnyhh0Nt; spf=pass (imf17.hostedemail.com: domain of songmuchun@bytedance.com designates 209.85.216.52 as permitted sender) smtp.mailfrom=songmuchun@bytedance.com; dmarc=pass (policy=none) header.from=bytedance.com X-HE-Tag: 1650349441-836404 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 Thu, Apr 14, 2022 at 11:10:01AM +0800, Muchun Song wrote: > On Wed, Apr 13, 2022 at 12:08:04PM -0700, Andrew Morton wrote: > > On Wed, 13 Apr 2022 22:47:45 +0800 Muchun Song wrote: > > > > > If the size of "struct page" is not the power of two but with the feature > > > of minimizing overhead of struct page associated with each HugeTLB is > > > enabled, then the vmemmap pages of HugeTLB will be corrupted after > > > remapping (panic is about to happen in theory). But this only exists when > > > !CONFIG_MEMCG && !CONFIG_SLUB on x86_64. However, it is not a conventional > > > configuration nowadays. So it is not a real word issue, just the result > > > of a code review. > > > > The patch does add a whole bunch of tricky junk to address something > > which won't happen. How about we simply disable > > CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP if (!CONFIG_MEMCG && > > !CONFIG_SLUB)? > > > > I'm afraid not. The size of 'struct page' also depends on > LAST_CPUPID_NOT_IN_PAGE_FLAGS which could be defined > when CONFIG_NODES_SHIFT or CONFIG_KASAN_SW_TAGS > or CONFIG_NR_CPUS is configured with a large value. Then > the size would be more than 64 bytes. > > Seems like the approach [1] is more simple and feasible, Sorry, forgot to post the Link. [1] https://lore.kernel.org/all/20220323125523.79254-2-songmuchun@bytedance.com/ > which also could prevent the users from doing unexpected > configurations, however, it is objected by Masahiro. > Shall we look back at the approach again? > Hi all, Friendly ping. I have implemented 3 approaches to address this issue. 1) V8 has added a lot of tricky code. 2) V5 has added a feadback from Kbuild to Kconfig, as Masahiro said, it is terrible. 3) V1 [2] has added a check of is_power_of_2() into hugetlb_vmemmap.c. Iterated and explored through 8 versions, v1 seems to be the easiest way to address this. I think reusing v1 may be the best choice now. What do you think? [2] https://lore.kernel.org/all/20220228071022.26143-2-songmuchun@bytedance.com/ Thanks.