From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-131.freemail.mail.aliyun.com (out30-131.freemail.mail.aliyun.com [115.124.30.131]) (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 D614E38945C for ; Tue, 7 Apr 2026 07:08:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775545691; cv=none; b=iydMIHjBki2r8ws5A2g3+71iQifZcssuhUdYhEoH86g/QTfHfS2KOiR2dJI9g8EfSzaSjmdTW8kxUfKkQbGE19i+Ey+Do1A3ytYZHUD0wdL8cyzWeuFY5fdkrx8eohJ8xevxqFtnrKbL4HSCPK5CPd2WTn7YeRJ6I5+wMvjub4E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775545691; c=relaxed/simple; bh=WLJjZzdTwzcUcJk9bvFHxZ9viW0NpJFC9ujVWRvXL4Q=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=WBsFWDn8WfkoYEOMmFl3+9V9ZgpkThKJTKNFK9724xue21UegByMNjyoNDnzmskn7ZLhhdJbhTOMkTri6AFLxDBLXCBuP5Yvqhpkb729RRN22VqAhBB0QQRF8SOaBi6R4nKQF6NB2MEMv2a6dkH8MZRFz/SxX0Z8F3W97IM6XJQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=D+KXJR/t; arc=none smtp.client-ip=115.124.30.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="D+KXJR/t" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1775545685; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=HY/zlCuL7i3/pdix1lf310z8fi6VjoWifT+fq5jE3pI=; b=D+KXJR/tlPqMvkbzwVf3DaFlTl4XQiCTsiMfI9EM9rVuwQPQnGxP6qCixtCyF8L5HgVxrDKj/SmnE2cCAz0FzE6wPu/sjCJf0y+FvOn0F3XUpqcYUnpp2V2hyGx6dxw2eLIQpxz1YFw522CUxBeVuDFsRSrHRsIrukrBz/0ROEE= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R831e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033032089153;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---0X0axiWU_1775545684; Received: from 30.74.144.138(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X0axiWU_1775545684 cluster:ay36) by smtp.aliyun-inc.com; Tue, 07 Apr 2026 15:08:05 +0800 Message-ID: Date: Tue, 7 Apr 2026 15:08:04 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm: shmem: don't set large-order range for internal anonymous shmem mapping To: Lance Yang Cc: akpm@linux-foundation.org, hughd@google.com, willy@infradead.org, ziy@nvidia.com, david@kernel.org, ljs@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20260407064903.69017-1-lance.yang@linux.dev> From: Baolin Wang In-Reply-To: <20260407064903.69017-1-lance.yang@linux.dev> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/7/26 2:49 PM, Lance Yang wrote: > > On Tue, Apr 07, 2026 at 02:07:27PM +0800, Baolin Wang wrote: >> Anonymous shmem large order allocations are dynamically controlled via the >> global THP sysfs knob (/sys/kernel/mm/transparent_hugepage/shmem_enabled) >> and the per-size mTHP knobs (/sys/kernel/mm/transparent_hugepage/hugepages-kB/shmem_enabled). >> >> Therefore, anonymous shmem uses shmem_allowable_huge_orders() to check >> which large orders are allowed, rather than relying on mapping_max_folio_order(). >> Moreover, mapping_max_folio_order() is intended to control large order >> allocations only for tmpfs mounts. Clarify this by not setting a large-order >> range for internal anonymous shmem mappings, to avoid confusion, as discussed >> in the previous thread[1]. >> >> [1] https://lore.kernel.org/all/ec927492-4577-4192-8fad-85eb1bb43121@linux.alibaba.com/ >> Signed-off-by: Baolin Wang >> --- >> mm/shmem.c | 13 +++++++++++-- >> 1 file changed, 11 insertions(+), 2 deletions(-) >> >> diff --git a/mm/shmem.c b/mm/shmem.c >> index 4ecefe02881d..a60fe067969c 100644 >> --- a/mm/shmem.c >> +++ b/mm/shmem.c >> @@ -3088,8 +3088,17 @@ static struct inode *__shmem_get_inode(struct mnt_idmap *idmap, >> if (sbinfo->noswap) >> mapping_set_unevictable(inode->i_mapping); >> >> - /* Don't consider 'deny' for emergencies and 'force' for testing */ >> - if (sbinfo->huge) >> + /* >> + * Only set the large order range for tmpfs mounts. The large order >> + * selection for the internal anonymous shmem mount is configured >> + * dynamically via the 'shmem_enabled' interfaces, so there is no >> + * need to set a large order range for the internal anonymous shmem >> + * mapping. >> + * >> + * Note: Don't consider 'deny' for emergencies and 'force' for >> + * testing. >> + */ >> + if (sbinfo->huge && !(sb->s_flags & SB_KERNMOUNT)) > > FWIW, SB_KERNMOUNT is broader than "internal anonymous shmem" and covers > all shm_mnt users too. > > So maybe "internal shmem mount" would be a better description of what > this code is actually checking. Right, good point. Will fix. Thanks.