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 6671EC30653 for ; Thu, 4 Jul 2024 18:43:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CDA226B00BB; Thu, 4 Jul 2024 14:43:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C652E6B00BC; Thu, 4 Jul 2024 14:43:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AB68B6B00BD; Thu, 4 Jul 2024 14:43:45 -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 82E6F6B00BB for ; Thu, 4 Jul 2024 14:43:45 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 20B1F1610C7 for ; Thu, 4 Jul 2024 18:43:45 +0000 (UTC) X-FDA: 82302944010.09.F76702C Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf24.hostedemail.com (Postfix) with ESMTP id BC081180017 for ; Thu, 4 Jul 2024 18:43:42 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=MdOagRrY; spf=none (imf24.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720118611; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=sNKtxBcfq1FOj6FTpkpQvKnBvmpEW5e+Aixwe6zCgS0=; b=vNTtGOz2nDiouMyGIRPCWgPM3onENdpzxqChzvVp023Ge4Jlr3ArgnF5DwcQr9cg2nVHTX ihJheudUs0OnwwoqFQfNr9bjQenR3jnEv4ZcoleOVY5fvtSH9PxfEurHRM8QNDH1ChBJu1 NxvY2/bLVEjhgOLpPMwbOK9FArXhsgs= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=MdOagRrY; spf=none (imf24.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720118611; a=rsa-sha256; cv=none; b=ROYuc+FPDuWDFNOapjSdxYeD2qWtf3/eOgVrRUG8NFYwo6mQhXqyvoLgK66RDOnIrmOUeX aSFp8VSn9VC3BwLSCnvM6FvJBQkdUznvQ/c9lVNUKKYYcIMQh3RnN01R1d6BtOYaOahj0B QI6Fqm1c6YpV8P3dWmEdeTabwQjGQlE= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=sNKtxBcfq1FOj6FTpkpQvKnBvmpEW5e+Aixwe6zCgS0=; b=MdOagRrY9qMVl0YUfx5iwBc0EE 0P1KFELrr68trhEYby80unYdLWGwZY5N0u0YpRLhVlL6IEnPzuwSLdigi3cOVSS3wn+kScJfSw+h5 w1sDlmuAIK+0W7M6umWLTTAsO8h9Dn1FzwMWR3cCMiIoXCaCvEvjX8DqP2tLlxOt6gxDxDyyQ7AY+ aWq5cx3r2fh4tOgkRPVVOBwrsoeU/twYCEkcU2M4mkZzJd1Nn8x3Prj7/FwE3NziISXnft/matHFc zx8bzFhPHBBrkmBClkKgh2WGbxx3PSKmDTGmOhXPfNoB7KihOQ7+8ioMSBxinnpbgJiZ9oUokqYBY Wry0GP4w==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1sPRQU-000000038qQ-0kqN; Thu, 04 Jul 2024 18:43:26 +0000 Date: Thu, 4 Jul 2024 19:43:26 +0100 From: Matthew Wilcox To: Baolin Wang Cc: akpm@linux-foundation.org, hughd@google.com, david@redhat.com, wangkefeng.wang@huawei.com, ying.huang@intel.com, 21cnbao@gmail.com, ryan.roberts@arm.com, shy828301@gmail.com, ziy@nvidia.com, ioworker0@gmail.com, da.gomez@samsung.com, p.raghav@samsung.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 0/6] add mTHP support for anonymous shmem Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: BC081180017 X-Stat-Signature: ctkyruqhdpywouyg169wf93wpbww7ji1 X-HE-Tag: 1720118622-97853 X-HE-Meta: U2FsdGVkX19X+RS9kEzXL7FyXp9p7RnII1eK/IZvlcaJMr2Dh8MPDD8CIoliXxsDZSavg2q46ouu+Bh3bSmwre0y2wCghO+WsY0ldnzt3exaPsSJOBB3e7OW+nXhh9ok4uKlO8RxlEnLma9zg0nsCHaljoyi7Kw5KAo3T2kRRTL664q9QZXfRDfArxiLHdeb56dtLWB6CPZc3AxCG6rkkJMt5IRgA/kWWAXVaeUVieoAtZiDPvo7+SrqlqAXMGSwJVc14iytMB28aZhc2KZFOIg3w/sPXSjwod+ySUSM/fMFLUMtQDL0EgPuoixgzmGu5wj8/2/6FJM0vxvti1m8PSBhyGn5BpHOMrZMg5mvyfqVVCVR9nG1KkcrUuoHq4te90udNLS5VrKmVRJajOKOCoXcXkB6QwWKd4Ffp/I3TRgiP71DcAznjqtCKY62LRpOpGkG8OV9s8Y+iBvX3FcYkMq7Dppy/TEt5VHx78hQANxF0MrEjbJjGXZU1UT7pVfjCxdwazIToAqfmhGPtdXdWNqTx6jbyx1Vfg/PBvvrQ10My6kTvcBwXrcWkA0jarzybZzphaWo/figLiVNT6r/vm99UqUaugS1QgOQOYRSxElgH2nNuIViv4/EYv4wWpsTcDKbFFV5XGkmKaveIWjo8wedzlyK3a9FkSxOjqreO1BXRv3oAqx7BxjuRGv9vv2uHGyCzgzCBClBVxJMPBdRj4zgz4eoPIM4k5Br4awCHdfrI4SDkPKF+16WZignWUExka49cuTUao1J4RXFM53WR2oroQmwunn7ofTkJO4lKtB62LIpzNY5/lss4S1fFa3OddyxAGzK9rStV8A9dBmN2IhQQH0iW7aZaxBQHCWph5rISl0GzV4Hn1EE1FBz/M/s4INXACuJ4q1VkdXxYRcP7wVO2fWVhLH5coUjvyt8K/YVxpK+pa9j7ZeirfqCUy1pUjHDokFFWP7si6HsdJJ Fuj7bK5e uL6rnjcJHGKui84KT2g5Iry55AFBMqQY8nUNmJ1rpT+EzkuKGtoPV8PVFj8VoEvkMg44fE9k2xOU9p9HyKZT8f1ZiMo3+Ic17sEvxoLGfSjHcOIRk3IM6wIAZAkfjLmnGbEGA/XSNjdBnFw/3KeVSRTmNEZzXOzbRzsUe1Byx/9sski6LhUsK+MuKLT5rE8sStorTsl9hVo2lXgJy9C2ivbyyLw== 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: List-Subscribe: List-Unsubscribe: On Tue, Jun 11, 2024 at 06:11:04PM +0800, Baolin Wang wrote: > Anonymous pages have already been supported for multi-size (mTHP) allocation > through commit 19eaf44954df, that can allow THP to be configured through the > sysfs interface located at '/sys/kernel/mm/transparent_hugepage/hugepage-XXkb/enabled'. > > However, the anonymous shmem will ignore the anonymous mTHP rule configured > through the sysfs interface, and can only use the PMD-mapped THP, that is not > reasonable. Many implement anonymous page sharing through mmap(MAP_SHARED | > MAP_ANONYMOUS), especially in database usage scenarios, therefore, users expect > to apply an unified mTHP strategy for anonymous pages, also including the > anonymous shared pages, in order to enjoy the benefits of mTHP. For example, > lower latency than PMD-mapped THP, smaller memory bloat than PMD-mapped THP, > contiguous PTEs on ARM architecture to reduce TLB miss etc. OK, this makes sense. > As discussed in the bi-weekly MM meeting[1], the mTHP controls should control > all of shmem, not only anonymous shmem, but support will be added iteratively. > Therefore, this patch set starts with support for anonymous shmem. But then this doesn't. You say first that users want the same controls to control all anonymous memory, then you introduce a completely separate set of controls for shared anonymous memory. shmem has two uses: - MAP_ANONYMOUS | MAP_SHARED (this patch set) - tmpfs For the second use case we don't want controls *at all*, we want the same heiristics used for all other filesystems to apply to tmpfs. There's no reason to have separate controls for choosing folio size in shmem. > The primary strategy is similar to supporting anonymous mTHP. Introduce > a new interface '/mm/transparent_hugepage/hugepage-XXkb/shmem_enabled', > which can have almost the same values as the top-level > '/sys/kernel/mm/transparent_hugepage/shmem_enabled', with adding a new > additional "inherit" option and dropping the testing options 'force' and > 'deny'. By default all sizes will be set to "never" except PMD size, which > is set to "inherit". This ensures backward compatibility with the anonymous > shmem enabled of the top level, meanwhile also allows independent control of > anonymous shmem enabled for each mTHP.