Loading Documentation/vm/frontswap.txt +37 −22 Original line number Diff line number Diff line .. _frontswap: ========= Frontswap ========= Frontswap provides a "transcendent memory" interface for swap pages. In some environments, dramatic performance savings may be obtained because swapped pages are saved in RAM (or a RAM-like device) instead of a swap disk. (Note, frontswap -- and cleancache (merged at 3.0) -- are the "frontends" (Note, frontswap -- and :ref:`cleancache` (merged at 3.0) -- are the "frontends" and the only necessary changes to the core kernel for transcendent memory; all other supporting code -- the "backends" -- is implemented as drivers. See the LWN.net article "Transcendent memory in a nutshell" for a detailed overview of frontswap and related kernel parts: https://lwn.net/Articles/454795/ ) See the LWN.net article `Transcendent memory in a nutshell`_ for a detailed overview of frontswap and related kernel parts) .. _Transcendent memory in a nutshell: https://lwn.net/Articles/454795/ Frontswap is so named because it can be thought of as the opposite of a "backing" store for a swap device. The storage is assumed to be Loading Loading @@ -50,19 +57,27 @@ or the store fails AND the page is invalidated. This ensures stale data may never be obtained from frontswap. If properly configured, monitoring of frontswap is done via debugfs in the /sys/kernel/debug/frontswap directory. The effectiveness of the `/sys/kernel/debug/frontswap` directory. The effectiveness of frontswap can be measured (across all swap devices) with: failed_stores - how many store attempts have failed loads - how many loads were attempted (all should succeed) succ_stores - how many store attempts have succeeded invalidates - how many invalidates were attempted ``failed_stores`` how many store attempts have failed ``loads`` how many loads were attempted (all should succeed) ``succ_stores`` how many store attempts have succeeded ``invalidates`` how many invalidates were attempted A backend implementation may provide additional metrics. FAQ === 1) Where's the value? * Where's the value? When a workload starts swapping, performance falls through the floor. Frontswap significantly increases performance in many such workloads by Loading Loading @@ -117,7 +132,7 @@ A KVM implementation is underway and has been RFC'ed to lkml. And, using frontswap, investigation is also underway on the use of NVM as a memory extension technology. 2) Sure there may be performance advantages in some situations, but * Sure there may be performance advantages in some situations, but what's the space/time overhead of frontswap? If CONFIG_FRONTSWAP is disabled, every frontswap hook compiles into Loading Loading @@ -148,7 +163,7 @@ pressure that can potentially outweigh the other advantages. A backend, such as zcache, must implement policies to carefully (but dynamically) manage memory limits to ensure this doesn't happen. 3) OK, how about a quick overview of what this frontswap patch does * OK, how about a quick overview of what this frontswap patch does in terms that a kernel hacker can grok? Let's assume that a frontswap "backend" has registered during Loading Loading @@ -188,7 +203,7 @@ and (potentially) a swap device write are replaced by a "frontswap backend store" and (possibly) a "frontswap backend loads", which are presumably much faster. 4) Can't frontswap be configured as a "special" swap device that is * Can't frontswap be configured as a "special" swap device that is just higher priority than any real swap device (e.g. like zswap, or maybe swap-over-nbd/NFS)? Loading Loading @@ -240,7 +255,7 @@ installation, frontswap is useless. Swapless portable devices can still use frontswap but a backend for such devices must configure some kind of "ghost" swap device and ensure that it is never used. 5) Why this weird definition about "duplicate stores"? If a page * Why this weird definition about "duplicate stores"? If a page has been previously successfully stored, can't it always be successfully overwritten? Loading @@ -254,7 +269,7 @@ the old data and ensure that it is no longer accessible. Since the swap subsystem then writes the new data to the read swap device, this is the correct course of action to ensure coherency. 6) What is frontswap_shrink for? * What is frontswap_shrink for? When the (non-frontswap) swap subsystem swaps out a page to a real swap device, that page is only taking up low-value pre-allocated disk Loading @@ -267,7 +282,7 @@ to "repatriate" pages sent to a remote machine back to the local machine; this is driven using the frontswap_shrink mechanism when memory pressure subsides. 7) Why does the frontswap patch create the new include file swapfile.h? * Why does the frontswap patch create the new include file swapfile.h? The frontswap code depends on some swap-subsystem-internal data structures that have, over the years, moved back and forth between Loading Loading
Documentation/vm/frontswap.txt +37 −22 Original line number Diff line number Diff line .. _frontswap: ========= Frontswap ========= Frontswap provides a "transcendent memory" interface for swap pages. In some environments, dramatic performance savings may be obtained because swapped pages are saved in RAM (or a RAM-like device) instead of a swap disk. (Note, frontswap -- and cleancache (merged at 3.0) -- are the "frontends" (Note, frontswap -- and :ref:`cleancache` (merged at 3.0) -- are the "frontends" and the only necessary changes to the core kernel for transcendent memory; all other supporting code -- the "backends" -- is implemented as drivers. See the LWN.net article "Transcendent memory in a nutshell" for a detailed overview of frontswap and related kernel parts: https://lwn.net/Articles/454795/ ) See the LWN.net article `Transcendent memory in a nutshell`_ for a detailed overview of frontswap and related kernel parts) .. _Transcendent memory in a nutshell: https://lwn.net/Articles/454795/ Frontswap is so named because it can be thought of as the opposite of a "backing" store for a swap device. The storage is assumed to be Loading Loading @@ -50,19 +57,27 @@ or the store fails AND the page is invalidated. This ensures stale data may never be obtained from frontswap. If properly configured, monitoring of frontswap is done via debugfs in the /sys/kernel/debug/frontswap directory. The effectiveness of the `/sys/kernel/debug/frontswap` directory. The effectiveness of frontswap can be measured (across all swap devices) with: failed_stores - how many store attempts have failed loads - how many loads were attempted (all should succeed) succ_stores - how many store attempts have succeeded invalidates - how many invalidates were attempted ``failed_stores`` how many store attempts have failed ``loads`` how many loads were attempted (all should succeed) ``succ_stores`` how many store attempts have succeeded ``invalidates`` how many invalidates were attempted A backend implementation may provide additional metrics. FAQ === 1) Where's the value? * Where's the value? When a workload starts swapping, performance falls through the floor. Frontswap significantly increases performance in many such workloads by Loading Loading @@ -117,7 +132,7 @@ A KVM implementation is underway and has been RFC'ed to lkml. And, using frontswap, investigation is also underway on the use of NVM as a memory extension technology. 2) Sure there may be performance advantages in some situations, but * Sure there may be performance advantages in some situations, but what's the space/time overhead of frontswap? If CONFIG_FRONTSWAP is disabled, every frontswap hook compiles into Loading Loading @@ -148,7 +163,7 @@ pressure that can potentially outweigh the other advantages. A backend, such as zcache, must implement policies to carefully (but dynamically) manage memory limits to ensure this doesn't happen. 3) OK, how about a quick overview of what this frontswap patch does * OK, how about a quick overview of what this frontswap patch does in terms that a kernel hacker can grok? Let's assume that a frontswap "backend" has registered during Loading Loading @@ -188,7 +203,7 @@ and (potentially) a swap device write are replaced by a "frontswap backend store" and (possibly) a "frontswap backend loads", which are presumably much faster. 4) Can't frontswap be configured as a "special" swap device that is * Can't frontswap be configured as a "special" swap device that is just higher priority than any real swap device (e.g. like zswap, or maybe swap-over-nbd/NFS)? Loading Loading @@ -240,7 +255,7 @@ installation, frontswap is useless. Swapless portable devices can still use frontswap but a backend for such devices must configure some kind of "ghost" swap device and ensure that it is never used. 5) Why this weird definition about "duplicate stores"? If a page * Why this weird definition about "duplicate stores"? If a page has been previously successfully stored, can't it always be successfully overwritten? Loading @@ -254,7 +269,7 @@ the old data and ensure that it is no longer accessible. Since the swap subsystem then writes the new data to the read swap device, this is the correct course of action to ensure coherency. 6) What is frontswap_shrink for? * What is frontswap_shrink for? When the (non-frontswap) swap subsystem swaps out a page to a real swap device, that page is only taking up low-value pre-allocated disk Loading @@ -267,7 +282,7 @@ to "repatriate" pages sent to a remote machine back to the local machine; this is driven using the frontswap_shrink mechanism when memory pressure subsides. 7) Why does the frontswap patch create the new include file swapfile.h? * Why does the frontswap patch create the new include file swapfile.h? The frontswap code depends on some swap-subsystem-internal data structures that have, over the years, moved back and forth between Loading