From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-181.mta0.migadu.com (out-181.mta0.migadu.com [91.218.175.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 11B813769F9 for ; Wed, 3 Jun 2026 07:40:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780472442; cv=none; b=idS8WuFdb3C/TCEYlt2x8CN1VWfppjFHI0MyzKrUuDOIEwAnRV7kylNuxzVLWCoQvbJnDcnGgymQAO5rO9FzCcqolUqhWIQQi1gOW4C0YMPHQxnsiq7goK2bTgAANaPMTnMUKrGKZC6HmmGWWDZLTBLse9kDVewOLf1VOypzJSg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780472442; c=relaxed/simple; bh=8HFLDbJ9QzaRkjloGlvriHsL9+0dzda3+7tO/nVbrNE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=I/pNlBeMxMveZc8yPX9FqQHG0QgXkdBruE4hk+CXK5Dpl2LrPd/W+hR0QTucpdbXfbnMQg4NrMSVpmN97e7+Rs5J1ipOd3iAMpnvmY+oT+mEjN8ZFjwJabL7Clb7ckC99ehEA0eDCIiN9lgk6o+n1XNuITzxJ87QeC00aHC01kQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=mVA51zBR; arc=none smtp.client-ip=91.218.175.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="mVA51zBR" Message-ID: <3022f1ee-36c0-4714-be70-558617d6b59b@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1780472437; 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=llrvkQYvg/c/PyQA2OAu5UFeLx+nMQneljCzO+vWWr0=; b=mVA51zBR/5dynA8pMjdR1IaOEEmkns3y5bv7f1pcCNY0JoBl661k7kCkMqQQqrYhdDuS+F 22RAe5CDBpBcTdHW/LKynf9CUlyPgDBfGZW9R2Jstdc+p6StKeK9R/OYzzs5hYzEimlkp7 hGrOWlom+eeUBGzFN8hJ6uW+upgNJ1U= Date: Wed, 3 Jun 2026 15:40:24 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v5 14/14] mm: thp: always enable mTHP support Content-Language: en-US To: Baolin Wang , luizcap@redhat.com Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, david@kernel.org, ziy@nvidia.com, corbet@lwn.net, tsbogend@alpha.franken.de, maddy@linux.ibm.com, mpe@ellerman.id.au, agordeev@linux.ibm.com, gerald.schaefer@linux.ibm.com, hca@linux.ibm.com, gor@linux.ibm.com, x86@kernel.org, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, ira.weiny@intel.com, hughd@google.com, dave.hansen@linux.intel.com, djbw@kernel.org, vishal.l.verma@intel.com, dave.jiang@intel.com, akpm@linux-foundation.org, yintirui@huawei.com, ljs@kernel.org References: <8781a9a0f115705ee11884ed3184b65a1ce39923.1780066530.git.luizcap@redhat.com> <20260603064718.81699-1-lance.yang@linux.dev> <2132b0a3-1085-47cb-95ca-3aaa7f8ed44b@linux.alibaba.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Lance Yang In-Reply-To: <2132b0a3-1085-47cb-95ca-3aaa7f8ed44b@linux.alibaba.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 2026/6/3 15:23, Baolin Wang wrote: > > > On 6/3/26 2:47 PM, Lance Yang wrote: >> Hi Luiz, >> >> SHMEM_HUGE_FORCE still assumes PMD order in a few places. >> >> Is that expected? >> >> shmem_init() only sets the default inherit mask when PMD leaves are >> available. >> >>     if (!shmem_orders_configured && pgtable_has_pmd_leaves()) >>         huge_shmem_orders_inherit = BIT(HPAGE_PMD_ORDER); >> >> But shmem_parse_huge() rejects "force" unless the mask is exactly PMD >> order. >> >>     if (huge == SHMEM_HUGE_FORCE && >>         huge_shmem_orders_inherit != BIT(HPAGE_PMD_ORDER)) >>         return -EINVAL; >> >> Even if "force" is selected, shmem_huge_global_enabled() still return >> only PMD order. >> >>     if (shmem_huge_force || shmem_huge == SHMEM_HUGE_FORCE) >>         return maybe_pmd_order; >> >> and shmem_allowable_huge_orders() mask it out. >> >>     if (!pgtable_has_pmd_leaves()) >>         disabled_orders = BIT(PMD_ORDER); >> >>     if (!vma || !vma_is_anon_shmem(vma)) >>         return global_orders & ~disabled_orders; >> >> For anon shmem, it can also return 0 for same reason. >> >>     if (shmem_huge == SHMEM_HUGE_FORCE) >>         return READ_ONCE(huge_shmem_orders_inherit) & ~disabled_orders; >> >> Should SHMEM_HUGE_FORCE use the available mTHP orders below PMD when >> pgtable_has_pmd_leaves() is false? > > No. That's exactly the strategy we agreed on after lots of discussion: > 1. The options 'force' and 'deny' are dropped for mTHP interfaces, which > are rather testing artifacts from the old ages. > > 2. If top level value is 'force', then only PMD-sized hugepages have > enabled="inherit", otherwise configuration will be failed and vice versa. > > You can check commit 4b98995530b7 ("mm: shmem: add multi-size THP sysfs > interface for anonymous shmem") for more information. Ah, thanks Baolin, good to know that :D Cheers, Lance