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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E9D12C71153 for ; Mon, 28 Aug 2023 11:35:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231725AbjH1Ley (ORCPT ); Mon, 28 Aug 2023 07:34:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53748 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231776AbjH1Lea (ORCPT ); Mon, 28 Aug 2023 07:34:30 -0400 Received: from out-250.mta0.migadu.com (out-250.mta0.migadu.com [91.218.175.250]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 93350C3 for ; Mon, 28 Aug 2023 04:34:27 -0700 (PDT) Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1693222465; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DRnBVmo3DqIJBhnJXFu4mrZmcPdTw6TB48chGflHSQo=; b=jLDHp/fW0ZFEyBVC1B8yr1RaUdS0s11uyb5GHbfG6vpiBhjWbkUSTGxXUNjkyxMLbQgAEs 03I3jR5QDowd3vVakYqmXTWNcRvorVbJxTJHULOK5hpBSL4MaypJWxC9BU4H243VOocBOC g1tznq1EXlB2HAsMZ2msACd5tkSeenQ= Mime-Version: 1.0 Subject: Re: [v3 4/4] mm: hugetlb: Skip initialization of gigantic tail struct pages if freed by HVO X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: <20230825111836.1715308-5-usama.arif@bytedance.com> Date: Mon, 28 Aug 2023 19:33:46 +0800 Cc: Linux-MM , Mike Kravetz , Mike Rapoport , LKML , Muchun Song , fam.zheng@bytedance.com, liangma@liangbit.com, punit.agrawal@bytedance.com Content-Transfer-Encoding: 7bit Message-Id: <486CFF93-3BB1-44CD-B0A0-A47F560F2CAE@linux.dev> References: <20230825111836.1715308-1-usama.arif@bytedance.com> <20230825111836.1715308-5-usama.arif@bytedance.com> To: Usama Arif X-Migadu-Flow: FLOW_OUT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Aug 25, 2023, at 19:18, Usama Arif wrote: > > The new boot flow when it comes to initialization of gigantic pages > is as follows: > - At boot time, for a gigantic page during __alloc_bootmem_hugepage, > the region after the first struct page is marked as noinit. > - This results in only the first struct page to be > initialized in reserve_bootmem_region. As the tail struct pages are > not initialized at this point, there can be a significant saving > in boot time if HVO succeeds later on. > - Later on in the boot, HVO is attempted. If its successful, only the first > HUGETLB_VMEMMAP_RESERVE_SIZE / sizeof(struct page) - 1 tail struct pages > after the head struct page are initialized. If it is not successful, > then all of the tail struct pages are initialized. > > Signed-off-by: Usama Arif This edition is simpler than before ever, thanks for your work. There is premise that other subsystems do not access vmemmap pages before the initialization of vmemmap pages associated withe HugeTLB pages allocated from bootmem for your optimization. However, IIUC, the compacting path could access arbitrary struct page when memory fails to be allocated via buddy allocator. So we should make sure that those struct pages are not referenced in this routine. And I know if CONFIG_DEFERRED_STRUCT_PAGE_INIT is enabled, it will encounter the same issue, but I don't find any code to prevent this from happening. I need more time to confirm this, if someone already knows, please let me know, thanks. So I think HugeTLB should adopt the similar way to prevent this. Thanks.