linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@linux.vnet.ibm.com>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Richard Henderson <rth@twiddle.net>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Matt Turner <mattst88@gmail.com>, Tony Luck <tony.luck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	James Hogan <jhogan@kernel.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	kasan-dev@googlegroups.com, linux-alpha@vger.kernel.org,
	linux-ia64@vger.kernel.org, linux-mips@linux-mips.org,
	linuxppc-dev@lists.ozlabs.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, Mike Rapoport <rppt@linux.vnet.ibm.com>
Subject: [PATCH 03/32] docs/vm: cleancache.txt: convert to ReST format
Date: Wed, 21 Mar 2018 21:22:19 +0200	[thread overview]
Message-ID: <1521660168-14372-4-git-send-email-rppt@linux.vnet.ibm.com> (raw)
In-Reply-To: <1521660168-14372-1-git-send-email-rppt@linux.vnet.ibm.com>

Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
---
 Documentation/vm/cleancache.txt | 105 ++++++++++++++++++++++++----------------
 1 file changed, 62 insertions(+), 43 deletions(-)

diff --git a/Documentation/vm/cleancache.txt b/Documentation/vm/cleancache.txt
index e4b49df..68cba91 100644
--- a/Documentation/vm/cleancache.txt
+++ b/Documentation/vm/cleancache.txt
@@ -1,4 +1,11 @@
-MOTIVATION
+.. _cleancache:
+
+==========
+Cleancache
+==========
+
+Motivation
+==========
 
 Cleancache is a new optional feature provided by the VFS layer that
 potentially dramatically increases page cache effectiveness for
@@ -21,9 +28,10 @@ Transcendent memory "drivers" for cleancache are currently implemented
 in Xen (using hypervisor memory) and zcache (using in-kernel compressed
 memory) and other implementations are in development.
 
-FAQs are included below.
+:ref:`FAQs <faq>` are included below.
 
-IMPLEMENTATION OVERVIEW
+Implementation Overview
+=======================
 
 A cleancache "backend" that provides transcendent memory registers itself
 to the kernel's cleancache "frontend" by calling cleancache_register_ops,
@@ -80,22 +88,33 @@ different Linux threads are simultaneously putting and invalidating a page
 with the same handle, the results are indeterminate.  Callers must
 lock the page to ensure serial behavior.
 
-CLEANCACHE PERFORMANCE METRICS
+Cleancache Performance Metrics
+==============================
 
 If properly configured, monitoring of cleancache is done via debugfs in
-the /sys/kernel/debug/cleancache directory.  The effectiveness of cleancache
+the `/sys/kernel/debug/cleancache` directory.  The effectiveness of cleancache
 can be measured (across all filesystems) with:
 
-succ_gets	- number of gets that were successful
-failed_gets	- number of gets that failed
-puts		- number of puts attempted (all "succeed")
-invalidates	- number of invalidates attempted
+``succ_gets``
+	number of gets that were successful
+
+``failed_gets``
+	number of gets that failed
+
+``puts``
+	number of puts attempted (all "succeed")
+
+``invalidates``
+	number of invalidates attempted
 
 A backend implementation may provide additional metrics.
 
+.. _faq:
+
 FAQ
+===
 
-1) Where's the value? (Andrew Morton)
+* Where's the value? (Andrew Morton)
 
 Cleancache provides a significant performance benefit to many workloads
 in many environments with negligible overhead by improving the
@@ -137,8 +156,8 @@ device that stores pages of data in a compressed state.  And
 the proposed "RAMster" driver shares RAM across multiple physical
 systems.
 
-2) Why does cleancache have its sticky fingers so deep inside the
-   filesystems and VFS? (Andrew Morton and Christoph Hellwig)
+* Why does cleancache have its sticky fingers so deep inside the
+  filesystems and VFS? (Andrew Morton and Christoph Hellwig)
 
 The core hooks for cleancache in VFS are in most cases a single line
 and the minimum set are placed precisely where needed to maintain
@@ -168,9 +187,9 @@ filesystems in the future.
 The total impact of the hooks to existing fs and mm files is only
 about 40 lines added (not counting comments and blank lines).
 
-3) Why not make cleancache asynchronous and batched so it can
-   more easily interface with real devices with DMA instead
-   of copying each individual page? (Minchan Kim)
+* Why not make cleancache asynchronous and batched so it can more
+  easily interface with real devices with DMA instead of copying each
+  individual page? (Minchan Kim)
 
 The one-page-at-a-time copy semantics simplifies the implementation
 on both the frontend and backend and also allows the backend to
@@ -182,8 +201,8 @@ are avoided.  While the interface seems odd for a "real device"
 or for real kernel-addressable RAM, it makes perfect sense for
 transcendent memory.
 
-4) Why is non-shared cleancache "exclusive"?  And where is the
-   page "invalidated" after a "get"? (Minchan Kim)
+* Why is non-shared cleancache "exclusive"?  And where is the
+  page "invalidated" after a "get"? (Minchan Kim)
 
 The main reason is to free up space in transcendent memory and
 to avoid unnecessary cleancache_invalidate calls.  If you want inclusive,
@@ -193,7 +212,7 @@ be easily extended to add a "get_no_invalidate" call.
 
 The invalidate is done by the cleancache backend implementation.
 
-5) What's the performance impact?
+* What's the performance impact?
 
 Performance analysis has been presented at OLS'09 and LCA'10.
 Briefly, performance gains can be significant on most workloads,
@@ -206,7 +225,7 @@ single-core systems with slow memory-copy speeds, cleancache
 has little value, but in newer multicore machines, especially
 consolidated/virtualized machines, it has great value.
 
-6) How do I add cleancache support for filesystem X? (Boaz Harrash)
+* How do I add cleancache support for filesystem X? (Boaz Harrash)
 
 Filesystems that are well-behaved and conform to certain
 restrictions can utilize cleancache simply by making a call to
@@ -217,26 +236,26 @@ not enable the optional cleancache.
 
 Some points for a filesystem to consider:
 
-- The FS should be block-device-based (e.g. a ram-based FS such
-  as tmpfs should not enable cleancache)
-- To ensure coherency/correctness, the FS must ensure that all
-  file removal or truncation operations either go through VFS or
-  add hooks to do the equivalent cleancache "invalidate" operations
-- To ensure coherency/correctness, either inode numbers must
-  be unique across the lifetime of the on-disk file OR the
-  FS must provide an "encode_fh" function.
-- The FS must call the VFS superblock alloc and deactivate routines
-  or add hooks to do the equivalent cleancache calls done there.
-- To maximize performance, all pages fetched from the FS should
-  go through the do_mpag_readpage routine or the FS should add
-  hooks to do the equivalent (cf. btrfs)
-- Currently, the FS blocksize must be the same as PAGESIZE.  This
-  is not an architectural restriction, but no backends currently
-  support anything different.
-- A clustered FS should invoke the "shared_init_fs" cleancache
-  hook to get best performance for some backends.
-
-7) Why not use the KVA of the inode as the key? (Christoph Hellwig)
+  - The FS should be block-device-based (e.g. a ram-based FS such
+    as tmpfs should not enable cleancache)
+  - To ensure coherency/correctness, the FS must ensure that all
+    file removal or truncation operations either go through VFS or
+    add hooks to do the equivalent cleancache "invalidate" operations
+  - To ensure coherency/correctness, either inode numbers must
+    be unique across the lifetime of the on-disk file OR the
+    FS must provide an "encode_fh" function.
+  - The FS must call the VFS superblock alloc and deactivate routines
+    or add hooks to do the equivalent cleancache calls done there.
+  - To maximize performance, all pages fetched from the FS should
+    go through the do_mpag_readpage routine or the FS should add
+    hooks to do the equivalent (cf. btrfs)
+  - Currently, the FS blocksize must be the same as PAGESIZE.  This
+    is not an architectural restriction, but no backends currently
+    support anything different.
+  - A clustered FS should invoke the "shared_init_fs" cleancache
+    hook to get best performance for some backends.
+
+* Why not use the KVA of the inode as the key? (Christoph Hellwig)
 
 If cleancache would use the inode virtual address instead of
 inode/filehandle, the pool id could be eliminated.  But, this
@@ -251,7 +270,7 @@ of cleancache would be lost because the cache of pages in cleanache
 is potentially much larger than the kernel pagecache and is most
 useful if the pages survive inode cache removal.
 
-8) Why is a global variable required?
+* Why is a global variable required?
 
 The cleancache_enabled flag is checked in all of the frequently-used
 cleancache hooks.  The alternative is a function call to check a static
@@ -262,14 +281,14 @@ global variable allows cleancache to be enabled by default at compile
 time, but have insignificant performance impact when cleancache remains
 disabled at runtime.
 
-9) Does cleanache work with KVM?
+* Does cleanache work with KVM?
 
 The memory model of KVM is sufficiently different that a cleancache
 backend may have less value for KVM.  This remains to be tested,
 especially in an overcommitted system.
 
-10) Does cleancache work in userspace?  It sounds useful for
-   memory hungry caches like web browsers.  (Jamie Lokier)
+* Does cleancache work in userspace?  It sounds useful for
+  memory hungry caches like web browsers.  (Jamie Lokier)
 
 No plans yet, though we agree it sounds useful, at least for
 apps that bypass the page cache (e.g. O_DIRECT).
-- 
2.7.4

  parent reply	other threads:[~2018-03-21 19:23 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-21 19:22 [PATCH 00/32] docs/vm: convert to ReST format Mike Rapoport
2018-03-21 19:22 ` [PATCH 01/32] docs/vm: active_mm.txt " Mike Rapoport
2018-03-21 19:22 ` [PATCH 02/32] docs/vm: balance: " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport [this message]
2018-03-21 19:22 ` [PATCH 04/32] docs/vm: frontswap.txt: " Mike Rapoport
2018-03-21 19:22 ` [PATCH 05/32] docs/vm: highmem.txt: " Mike Rapoport
2018-03-21 19:22 ` [PATCH 06/32] docs/vm: hmm.txt: " Mike Rapoport
2018-03-21 19:22 ` [PATCH 07/32] docs/vm: hugetlbpage.txt: " Mike Rapoport
2018-03-21 19:22 ` [PATCH 08/32] docs/vm: hugetlbfs_reserv.txt: " Mike Rapoport
2018-03-21 19:22 ` [PATCH 09/32] docs/vm: hwpoison.txt: " Mike Rapoport
2018-03-21 19:22 ` [PATCH 10/32] docs/vm: idle_page_tracking.txt: " Mike Rapoport
2018-03-21 19:22 ` [PATCH 11/32] docs/vm: ksm.txt: " Mike Rapoport
2018-03-21 19:22 ` [PATCH 12/32] docs/vm: mmu_notifier.txt: " Mike Rapoport
2018-03-21 19:22 ` [PATCH 13/32] docs/vm: numa_memory_policy.txt: " Mike Rapoport
2018-03-21 19:22 ` [PATCH 14/32] docs/vm: overcommit-accounting: " Mike Rapoport
2018-03-21 19:22 ` [PATCH 15/32] docs/vm: page_frags " Mike Rapoport
2018-03-21 19:22 ` [PATCH 16/32] docs/vm: numa: " Mike Rapoport
2018-03-21 19:22 ` [PATCH 17/32] docs/vm: pagemap.txt: " Mike Rapoport
2018-03-21 19:22 ` [PATCH 18/32] docs/vm: page_migration: " Mike Rapoport
2018-03-21 19:22 ` [PATCH 19/32] docs/vm: page_owner: " Mike Rapoport
2018-03-21 19:22 ` [PATCH 20/32] docs/vm: remap_file_pages.txt: conert " Mike Rapoport
2018-03-21 19:22 ` [PATCH 21/32] docs/vm: slub.txt: convert " Mike Rapoport
2018-03-21 19:22 ` [PATCH 22/32] docs/vm: soft-dirty.txt: " Mike Rapoport
2018-03-21 19:22 ` [PATCH 23/32] docs/vm: split_page_table_lock: " Mike Rapoport
2018-03-21 19:22 ` [PATCH 24/32] docs/vm: swap_numa.txt: " Mike Rapoport
2018-03-21 19:22 ` [PATCH 25/32] docs/vm: transhuge.txt: " Mike Rapoport
2018-03-21 19:22 ` [PATCH 26/32] docs/vm: unevictable-lru.txt: " Mike Rapoport
2018-03-21 19:22 ` [PATCH 27/32] docs/vm: userfaultfd.txt: " Mike Rapoport
2018-03-21 19:22 ` [PATCH 28/32] docs/vm: z3fold.txt: " Mike Rapoport
2018-03-21 19:22 ` [PATCH 29/32] docs/vm: zsmalloc.txt: " Mike Rapoport
2018-03-21 19:22 ` [PATCH 30/32] docs/vm: zswap.txt: " Mike Rapoport
2018-03-21 19:22 ` [PATCH 31/32] docs/vm: rename documentation files to .rst Mike Rapoport
2018-03-21 19:22 ` [PATCH 32/32] docs/vm: add index.rst and link MM documentation to top level index Mike Rapoport
2018-03-29 21:46 ` [PATCH 00/32] docs/vm: convert to ReST format Jonathan Corbet
2018-04-01  6:38   ` Mike Rapoport
2018-04-10 10:23     ` Mike Rapoport
2018-04-13 19:55     ` Jonathan Corbet
2018-04-13 20:21       ` Matthew Wilcox
2018-04-15 17:29         ` Mike Rapoport
2018-04-15 17:36       ` Mike Rapoport
2018-04-16 20:35         ` Jonathan Corbet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1521660168-14372-4-git-send-email-rppt@linux.vnet.ibm.com \
    --to=rppt@linux.vnet.ibm.com \
    --cc=aryabinin@virtuozzo.com \
    --cc=corbet@lwn.net \
    --cc=fenghua.yu@intel.com \
    --cc=ink@jurassic.park.msu.ru \
    --cc=jhogan@kernel.org \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mattst88@gmail.com \
    --cc=mpe@ellerman.id.au \
    --cc=ralf@linux-mips.org \
    --cc=rth@twiddle.net \
    --cc=tony.luck@intel.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).