From patchwork Thu Mar 9 23:05:44 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Chamberlain X-Patchwork-Id: 13168526 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 C067CC6FD1C for ; Thu, 9 Mar 2023 23:06:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BA2EF280004; Thu, 9 Mar 2023 18:05:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B079A280002; Thu, 9 Mar 2023 18:05:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 86C4D280004; Thu, 9 Mar 2023 18:05:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 79D1B280002 for ; Thu, 9 Mar 2023 18:05:58 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 554B1407B4 for ; Thu, 9 Mar 2023 23:05:58 +0000 (UTC) X-FDA: 80550894396.09.7F9AFD6 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf14.hostedemail.com (Postfix) with ESMTP id B10C6100014 for ; Thu, 9 Mar 2023 23:05:56 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b="oZkr/qx3"; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=none (imf14.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678403156; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=KhIOryYi/WjMt1G9oWTtfKzfZj1AUYZk+i6xawkBgBo=; b=cjeupL/WHTAQoxj2/lEcBdy1IbrpjuFlizdr5h6xlehQDnV7PBlwX7GkIHhbuPxv3YfGY5 RU9kiPIskdMAWxAA4idkhstMnxLREp390MXvaf1dlc7B7ogczQF+EDaiog4+gn1JcIQR6k 6LG6FWCzCAKfE5OqRiScN6JQQqBworQ= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b="oZkr/qx3"; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=none (imf14.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678403156; a=rsa-sha256; cv=none; b=tu7DqQbAAzbss3wsLUNL8sBQpyh3ST3gRgFA8IWy778e9OtdZv0Dev9mWeGgN5TylgWZ8A KYu2IgvqA6zxlTZjPHVryJVlcnmP939OZf5FzAiEf+YqmmmK94MBR2SibosBmmU9DElBCg A8vXGTReQhAbU85/WfEb/Ma5zG35izQ= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Sender:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From: Reply-To:Content-Type:Content-ID:Content-Description; bh=KhIOryYi/WjMt1G9oWTtfKzfZj1AUYZk+i6xawkBgBo=; b=oZkr/qx3wEVfj1+ZVhCpyCYUCM jPh9BtYO/JSVE8KrDiP2o4+eSvNFTDhlZZMAGxJNUISY7r5Y2UQ9kJ7YZ7cFxmcydxWagnOYed0Og wDztp8ZfqI7TdvS/7rrodGjB1hRbxyZoDbRSj2Mhdxfex4+EkVe/kcw4urS7yVzUCrelwyN4OH53M pAguCzkK7m39yc+D18Yqzw4LPOmZDxW1iRJDItZjlzSejD1aNkbTxRX0HfkUWjGtOOtW3KhfjHCIZ HVtJ04r4g8q08N0npmkuwuhmFDnKnU1F4T7o6wh3xbBAlS8F2RA2HFNXQ2VjZe2ygU7wxl1qrFmMu jmuVMOqQ==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1paPKW-00CIRa-Az; Thu, 09 Mar 2023 23:05:48 +0000 From: Luis Chamberlain To: hughd@google.com, akpm@linux-foundation.org, willy@infradead.org, brauner@kernel.org Cc: linux-mm@kvack.org, p.raghav@samsung.com, da.gomez@samsung.com, a.manzanares@samsung.com, dave@stgolabs.net, yosryahmed@google.com, keescook@chromium.org, mcgrof@kernel.org, patches@lists.linux.dev, linux-kernel@vger.kernel.org, David Hildenbrand Subject: [PATCH v2 5/6] shmem: update documentation Date: Thu, 9 Mar 2023 15:05:44 -0800 Message-Id: <20230309230545.2930737-6-mcgrof@kernel.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20230309230545.2930737-1-mcgrof@kernel.org> References: <20230309230545.2930737-1-mcgrof@kernel.org> MIME-Version: 1.0 X-Rspamd-Queue-Id: B10C6100014 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: ngeo8aocrnorsjbbcbabtmwdwu9htyeu X-HE-Tag: 1678403156-629320 X-HE-Meta: U2FsdGVkX1+vo2MwDiBHIkcPSw8A6G7K8u1hg/nGLjNg/NMMD3saKsj6iFTNiy3IFfRjVQoCbZk6wksQiZM9lf/v+lWOH32fJlSD2lNM/COD7nKmtgEAZjTxFBd6pc1GqEnR+f2fztmr03x9O+B566YGZs5LR1z3WitcH4DCh8Ff/JicQK0ON9tqtnwvWF8ThYDG5sWlx4SaUHdjASEJ4U3hhBqVdf2lsXcSZukN4KpWYnWtw2p7HFVUfvktZbqNU5Yc+C/ykSZWJaKYMTlY+KeEUSg5GUMLBcYoqJkzY9o/MDzmp880dlw2899MC9D1ji2ItmD5GJNE7S2pJwVM+wCMiWRlkvGpoXlDWPczIeRuycWxg7y/UqAGkMfnNK4klWTaFWstzjg/Icn2d054aS3mnccxho/q89OTFsa3fd4PQ8xphVJujOaP+l9HQ8XXnYIkmQzX1ErHla8QnyrndwopmlOqATuK74gb9Yj+z2I86DUCFcBun8yWGw6NB81/4rr4T7bfoldvM1wbg72yJm6GW2K4mEvITXEQDNlh4NstBJJZpKvpruwfrObve4JXyYgq/WNKyUV0uoBBqaDvFfECMM1uYGMaIzB/zs3VQyILygw7DoEQedvFCDemq5kohmIufoBYwiZPBBFKe19u8V2Q3TRvK6/TlhbX1UxSa9nIT8GomfdMJKks8nXgYsy6gw5EyUNz1umYclEhmqD2EoYxofA6MUaAA0G2BXGVHVZgdj4E8sSPOi7tOtcL9iv+ukJYkCrvjL+yBtyJDPbw9d+eUy1StHxQZwrLn3OiVBIxVzukV8u0Wi7sA9ZQ+oQYN6tT815rgrj4mUV8hArMd7BgaeAH9WorCadppIEBEx49HsD6LnjzIgn2x2vo+jtT0yKSXF+/qTNpPEY3X1tt9/tBALwj1aozyQuAyLjdASYZYB4pXOxZOc5ChsqTithPvNf5NCKIJPoWmTDhSBh oESIHfCS WxR+Xw/SJbXx1EGH746KsWN0j924LuV17pd/0ZSI/gmaDnqmDXyjZHSvssPzU4Au9g2DTN4KKmU3LLnttE+dTSZmezPgQTOb+y0HVXkK5XpWP3e1sw9TFqXlVjkl4jTSlJCFeA8oh1znCoEFzWKe9xpYzTDKDcv1GkVbzhJ9X/dCFIfiw9vYbjl6wLbASvtcj4CQITxbeBmd4lTthjb3DKUkGmHfIObFKCpHh5e9eIMwnkXtZZNBWBPZ+91tqGWXHai0OsgXlVzTUEn5Mo3ondOcRqP/Tz23Z/Ugzs6KetRsI06Ls4Gai0W1unZb9CKqCfTZb9cSN5gCm5g4TYPa3cQPP53QeVku6ihE7spv1fe7486SIGx0sscaCeRZFXw9A52LM7IRntEOpzMZt+r/Ur3TLl+unjO54bHD5hRULkNe/d1TYoV0zv0j0zQ== 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: Update the docs to reflect a bit better why some folks prefer tmpfs over ramfs and clarify a bit more about the difference between brd ramdisks. While at it, add THP docs for tmpfs, both the mount options and the sysfs file. Reviewed-by: Christian Brauner Reviewed-by: David Hildenbrand Signed-off-by: Luis Chamberlain --- Documentation/filesystems/tmpfs.rst | 57 +++++++++++++++++++++++++---- 1 file changed, 49 insertions(+), 8 deletions(-) diff --git a/Documentation/filesystems/tmpfs.rst b/Documentation/filesystems/tmpfs.rst index 0408c245785e..1ec9a9f8196b 100644 --- a/Documentation/filesystems/tmpfs.rst +++ b/Documentation/filesystems/tmpfs.rst @@ -13,14 +13,25 @@ everything stored therein is lost. tmpfs puts everything into the kernel internal caches and grows and shrinks to accommodate the files it contains and is able to swap -unneeded pages out to swap space. It has maximum size limits which can -be adjusted on the fly via 'mount -o remount ...' - -If you compare it to ramfs (which was the template to create tmpfs) -you gain swapping and limit checking. Another similar thing is the RAM -disk (/dev/ram*), which simulates a fixed size hard disk in physical -RAM, where you have to create an ordinary filesystem on top. Ramdisks -cannot swap and you do not have the possibility to resize them. +unneeded pages out to swap space, and supports THP. + +tmpfs extends ramfs with a few userspace configurable options listed and +explained further below, some of which can be reconfigured dynamically on the +fly using a remount ('mount -o remount ...') of the filesystem. A tmpfs +filesystem can be resized but it cannot be resized to a size below its current +usage. tmpfs also supports POSIX ACLs, and extended attributes for the +trusted.* and security.* namespaces. ramfs does not use swap and you cannot +modify any parameter for a ramfs filesystem. The size limit of a ramfs +filesystem is how much memory you have available, and so care must be taken if +used so to not run out of memory. + +An alternative to tmpfs and ramfs is to use brd to create RAM disks +(/dev/ram*), which allows you to simulate a block device disk in physical RAM. +To write data you would just then need to create an regular filesystem on top +this ramdisk. As with ramfs, brd ramdisks cannot swap. brd ramdisks are also +configured in size at initialization and you cannot dynamically resize them. +Contrary to brd ramdisks, tmpfs has its own filesystem, it does not rely on the +block layer at all. Since tmpfs lives completely in the page cache and on swap, all tmpfs pages will be shown as "Shmem" in /proc/meminfo and "Shared" in @@ -85,6 +96,36 @@ mount with such options, since it allows any user with write access to use up all the memory on the machine; but enhances the scalability of that instance in a system with many CPUs making intensive use of it. +tmpfs also supports Transparent Huge Pages which requires a kernel +configured with CONFIG_TRANSPARENT_HUGEPAGE and with huge supported for +your system (has_transparent_hugepage(), which is architecture specific). +The mount options for this are: + +====== ============================================================ +huge=0 never: disables huge pages for the mount +huge=1 always: enables huge pages for the mount +huge=2 within_size: only allocate huge pages if the page will be + fully within i_size, also respect fadvise()/madvise() hints. +huge=3 advise: only allocate huge pages if requested with + fadvise()/madvise() +====== ============================================================ + +There is a sysfs file which you can also use to control system wide THP +configuration for all tmpfs mounts, the file is: + +/sys/kernel/mm/transparent_hugepage/shmem_enabled + +This sysfs file is placed on top of THP sysfs directory and so is registered +by THP code. It is however only used to control all tmpfs mounts with one +single knob. Since it controls all tmpfs mounts it should only be used either +for emergency or testing purposes. The values you can set for shmem_enabled are: + +== ============================================================ +-1 deny: disables huge on shm_mnt and all mounts, for + emergency use +-2 force: enables huge on shm_mnt and all mounts, w/o needing + option, for testing +== ============================================================ tmpfs has a mount option to set the NUMA memory allocation policy for all files in that instance (if CONFIG_NUMA is enabled) - which can be