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 21444C71153 for ; Mon, 28 Aug 2023 11:34:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 73DB16B009B; Mon, 28 Aug 2023 07:34:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6EE106B009C; Mon, 28 Aug 2023 07:34:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5DC5C8E000E; Mon, 28 Aug 2023 07:34:30 -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 4EE406B009B for ; Mon, 28 Aug 2023 07:34:30 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 136B714037A for ; Mon, 28 Aug 2023 11:34:30 +0000 (UTC) X-FDA: 81173305500.01.0F7C721 Received: from out-249.mta0.migadu.com (out-249.mta0.migadu.com [91.218.175.249]) by imf10.hostedemail.com (Postfix) with ESMTP id E66C5C0003 for ; Mon, 28 Aug 2023 11:34:27 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="jLDHp/fW"; spf=pass (imf10.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.249 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693222468; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=DRnBVmo3DqIJBhnJXFu4mrZmcPdTw6TB48chGflHSQo=; b=tUAEWaaUfXLRTWdlFI7/vVn13OBMKbin4EtyW3dZqrz+nTWy3V9i+fo/OYa4JDNTAeKeXX eNw4XJZJtP5PoA2mHRs2NJ3q7DyaVnOClEukgHCqDFJHEc6Yk2QcAUXfXHJ6Chj9WjphZE ve7vemxWNaMG80hQyFGWrLoz9qdzqPg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693222468; a=rsa-sha256; cv=none; b=Rrz8z7HEMCCQimwNjzxyULjZxvob2CEqfJoSO92qPE7VFrejodx4HIDQHweu1to7BzHm/5 ewLFj5XuJAwNLDsuA6KEC42dKt1UJj1CX5OHL5V1XkS+F0iav7wi8Xyr6nY5EjivOa3AIa /Wy9LBxTJH/5Agnpo98lybaZ/V71l9c= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="jLDHp/fW"; spf=pass (imf10.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.249 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev 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 X-Rspamd-Queue-Id: E66C5C0003 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: xk6dumtjipi6fmfrk4cy9nfgz6htt97a X-HE-Tag: 1693222467-729408 X-HE-Meta: U2FsdGVkX1+jgp70omUpylIsh6BFnKsxg03m4KPSx1BlGU/2ceYeMB8Dz5k1obi4Ko7v5zo4t8b8yrf5CLbqBG/GUucpWhywMYvj3KIbQ5RZIdx2sIPHcAzbJ+3rVZA4pa99kx5wlPJQ4YBh3PK4LMnD0SVWvyID7sK5YE2fL44Ju0wCvRgOS6jTxTLllnzQId4Yr1xoK7sNz9e5qL1QJcmLmKuJNFSvdgHVVhbXNl0344w7lCWYoG/vpfHuScNy9ScVccLpkSwAC/dPaxI55JqLTVXMj4hV5SYF3sGVOVwGy+rrGDyuquTgVE7DhsE42/NhOEkd775wERNAkSsdJy9AuIzq8G9kF+t7jFbombBP33ZEOu4q8qyxa2XiMRCVrtSnpCckG43YNOzkM6n6Uc5DpqYYQ1lZFfo5W1veFWWnyVvzZvlyIEW3tIFEDVoty70zbhuGKk5u6nT2bYeW3bhhaMDaOTh+QNfX5c42RF44QczHNhBdLDTN5CDxQRh0o5VFkotqed2/ZbWZT81syoNu8QcowyNZjC9CxuxCZ4l+JBW6SGeMLS7/LqqCuoNfDUBHXB2pLU0Q4aSYjgGZPMTt2tBdQyNSNJ3/83L3983YqNBa5AltJv8WIxB1KxqLe4tZtolnEyVUyqe0ESNyuR9kv/cQa0InJkGMo6NvMJt3UrY/W7AJvDMXBdMS1I9Hm2hrFCUrqsykWT7CyVhoR2mmhu0sqaIGqRvqqJbEXCVCNnYz91IM+BlIusm6DY70Ke4aAiG2LLvl7SLTdIh+CUk3u/oLa05igr/Z2D+Zc1nMv231arQ4BBSFrEOAXWbFmQgj4WOj+VnrskX+9ndhucM3mGn1KgffahQlUDbKBhAKMlr3+8dDpfZ1jS0kcpEwi1cKlJFi16CMsFXsK0t7b464GuTyijIKtow76y46tgiJT2KA+0V68qPPhY9Zlei6auiq/XKktxhDVL4HsSq tA/DN3wo dHrmysy9CEs35dgDcL5/hIXxg39rrEuRTAWe0klg92VRW2A4LlqlFFwX7SWbE7Q+LuCgjhQNepF8/ZjnHyB57ng7TJPMlbLwlLqG+arCLU8O91/UaWegfl+Tn3RwVZhcFbze05NmfFzKscK+SYJL0iAx9T01UxAXvS4lpCEcqWYheab0= 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 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.