Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp407206pxm; Wed, 2 Mar 2022 18:36:02 -0800 (PST) X-Google-Smtp-Source: ABdhPJzEOWV9zAhv4Yqbe8eJ+1dVQV60Bfuzv+dv0O8L4tFrbqv5QxOwYiCs/LhCG+6i1pOpYrdf X-Received: by 2002:a17:90a:9306:b0:1bc:9256:5477 with SMTP id p6-20020a17090a930600b001bc92565477mr2986483pjo.170.1646274961641; Wed, 02 Mar 2022 18:36:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646274961; cv=none; d=google.com; s=arc-20160816; b=s8FBi8dQq15jrDXQd1Oo3eWgaMpqPxg0yuGk+mYqNfZYw2Zt0wvlT47+FbXgk7+CbS jiPQ530qQyWujOqlBGN5G1kIJsp7I0wqWAHKMIH2SoYnF/TalQlndu+iOMfdl2UKrnXF gCMRyd3sefonN+CQtWuiNUQuiKAguAgrUuVGrmdzJYoLVMBy52B9ib77PxCIeikrHspJ 7K/0tA7FaNm6C7nuVD81iIq4B/O8likWB8n/BvCYrLKmtVjF2ksxcRRCJP5E51nxSUnB MHhEGc2Q0gj9BQ88rvKdxzUQSw48k7UPM12xGs/jmiht4FrWqIvyOm6HrDogtluuO2ce W88g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=v2tz3AuOoQeFoLXvffTr2cIrrixjHNaOs+XLOL0KCfw=; b=DgBojIfTOQsKScyZnQ1dgm8UXs6d3mHctaadVfsnVyR0+rcm1rkL5NFOJoZYiTKSy5 KiR1AvIDgmdRQb0sJiZphZbYc1xTLmS8UQ+qnGfEMkRcm52wa7suBFz9adA1GfDzqqCj omPlYos3+4IjLKqHbpPsRZraDRmqAFWqZoUN/uTy382OrPNNy9hcvX5DPYDI+CazXdbi 74uLnsG2lleaNjCkV21apDSHYJnBXWzmSHK/w0bdmUqkGDDX4UMqgKaAS9MOywWWOg2D FEZcFeBLqCizMZJNqKCxX4bdNuBEyMdRZM0T1RCxZdPaFm1FC/AspJTLtRIPTegCI6JG 1HWQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b="Cf/ju3K8"; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id d19-20020a056a0024d300b004e1b9a1ecadsi896376pfv.53.2022.03.02.18.36.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Mar 2022 18:36:01 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b="Cf/ju3K8"; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0E7053B3F6; Wed, 2 Mar 2022 18:29:16 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231755AbiCCC3m (ORCPT + 99 others); Wed, 2 Mar 2022 21:29:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44208 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231753AbiCCC3j (ORCPT ); Wed, 2 Mar 2022 21:29:39 -0500 Received: from mail-yw1-x112d.google.com (mail-yw1-x112d.google.com [IPv6:2607:f8b0:4864:20::112d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A51923B2A4 for ; Wed, 2 Mar 2022 18:28:54 -0800 (PST) Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-2dc28791ecbso26639657b3.4 for ; Wed, 02 Mar 2022 18:28:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v2tz3AuOoQeFoLXvffTr2cIrrixjHNaOs+XLOL0KCfw=; b=Cf/ju3K84F49k8wI7YQgyVYv3aMiVSZ7LUjx6feXZrNHr1cnaJFLUrSSLIwOUaEdtV 9tVTIXdEla4GZAOr3bbyF+liAgp/0T6++nQbK7rLWODyVm5sULM4XB9QCYXoe73uBXgC d+cqehy56gj3gkfnaziTmIW+f6zLOu4MPFhb4ngMlS54sPtUdpqSJrSNZ++HhPn/5t0P jymhfGHsOU63FPtX5lGhPABzo6+5Jx+1Q7XxI6QiL6A7HW8EnZkmhCupezBUc+6PRaJc 3fLtt+boLXSQc1SWIb3suDEZuEkrIlFSBBJ2Y639LLAkGjCYgSJEmjZIiSQ5Zy/X4dv7 igpw== 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=v2tz3AuOoQeFoLXvffTr2cIrrixjHNaOs+XLOL0KCfw=; b=LtNRz460BHa7WWQ9X4jixoI2ZrA3mmuy60q9k4C0z4ncyHAFJ/v8BlbyCaDQd7XN9b qYnYr+By1grr5U4oURNAf9klbesbvfhsr5jY6sxomPFoKDZobbTJ+05peU0girLv6N+2 APYb84LvohKSiFbayfsa1KF5AGu2vIH5KgxAzpoLrgL8G1MVq27G6sw9pHY5v+ua1RLq ce1ElCh4XmANfev41IhpGy5N96daOIsQKqbgOKfAb+0tS7ZatZywHZuvNakeWvc+2YRq WuxHZPRvqASaXJNIk6aMhfzy3bvlZM3t6ONux/qD4xVwC+28WB5NXm2wg11xmJdcLIj/ VFKg== X-Gm-Message-State: AOAM532csaxmqOQ4XUCdZN9JUZmHKAWDm7EWv1qT2YByZgTzowC/YjL9 RknrqLZs/GUzxyx2J335Ap6FTBFzWtWhqm+K2NsJ3A== X-Received: by 2002:a81:5dd6:0:b0:2d6:3041:12e0 with SMTP id r205-20020a815dd6000000b002d6304112e0mr33446832ywb.331.1646274533419; Wed, 02 Mar 2022 18:28:53 -0800 (PST) MIME-Version: 1.0 References: <20220302083758.32528-1-songmuchun@bytedance.com> <20220302083758.32528-2-songmuchun@bytedance.com> In-Reply-To: From: Muchun Song Date: Thu, 3 Mar 2022 10:28:17 +0800 Message-ID: Subject: Re: [PATCH v2 1/3] mm: hugetlb: disable freeing vmemmap pages when struct page crosses page boundaries To: Mike Kravetz Cc: Jonathan Corbet , Andrew Morton , Luis Chamberlain , Kees Cook , Iurii Zaikin , Linux Doc Mailing List , LKML , Linux Memory Management List , Xiongchun duan , Muchun Song Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 3, 2022 at 8:25 AM Mike Kravetz wrote: > > On 3/2/22 00:37, Muchun Song wrote: > > If CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON is enabled and the size > > of "struct page" is not power of two, we cannot optimize vmemmap pages > > of HugeTLB pages. We should disable this feature in this case. > > I'll let you reply to the question from Luis, but IIUC there is no issue > today as "struct page" is certainly a power of two. This is more future > looking. Correct? Partly right. The size of "struct page" is not the power of two if !CONFIG_MEMCG && CONFIG_SLAB on x86_64. But it is not a conventional configuration nowadays. So it is not a critical problem. I am not sure if a Fixes tag is necessary. > > > Signed-off-by: Muchun Song > > --- > > mm/hugetlb_vmemmap.c | 11 +++++++++++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c > > index b3118dba0518..836d1117f08b 100644 > > --- a/mm/hugetlb_vmemmap.c > > +++ b/mm/hugetlb_vmemmap.c > > @@ -121,6 +121,17 @@ void __init hugetlb_vmemmap_init(struct hstate *h) > > if (!hugetlb_free_vmemmap_enabled()) > > return; > > > > + if (IS_ENABLED(CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON) && > > + !is_power_of_2(sizeof(struct page))) { > > + /* > > + * The hugetlb_free_vmemmap_enabled_key can be enabled when > > + * CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON. It should > > + * be disabled if "struct page" crosses page boundaries. > > + */ > > + static_branch_disable(&hugetlb_free_vmemmap_enabled_key); > > Should we possibly print a warning here as in the routine early_hugetlb_free_vmemmap_param? This is called once per hstate, so > perhaps pr_warn_once. Good point. Will do. Thanks.