Documentation/vm/frontswap.rst

9 swapped pages are saved in RAM (or a RAM-like device) instead of a swap disk.
11 (Note, frontswap -- and :ref:`cleancache` (merged at 3.0) -- are the "frontends"
13 all other supporting code -- the "backends" -- is implemented as drivers.
21 a synchronous concurrency-safe page-oriented "pseudo-RAM device" conforming
23 in-kernel compressed memory, aka "zcache", or future RAM-like devices);
24 this pseudo-RAM device is not directly accessible or addressable by the
25 kernel and is of unknown and possibly time-varying size.  The driver
50 in swap device writes is lost (and also a non-trivial performance advantage)
88 useful for write-balancing for some RAM-like devices).  Swap pages (and
89 evicted page-cache pages) are a great use for this kind of slower-than-RAM-
90 but-much-faster-than-disk "pseudo-RAM device" and the frontswap (and
92 and write -- and indirectly "name" -- the pages.
94 Frontswap -- and cleancache -- with a fairly small impact on the kernel,
95 provides a huge amount of flexibility for more dynamic, flexible RAM
100 that can be safely kept in RAM.  Zcache essentially trades off CPU
106 "RAMster" builds on zcache by adding "peer-to-peer" transcendent memory
108 as in zcache, but then "remotified" to another system's RAM.  This
109 allows RAM to be dynamically load-balanced back-and-forth as needed,
113 server configured with a large amount of RAM... without pre-configuring
114 how much of the RAM is available for each of the clients!
118 virtual machines.  This is really hard to do with RAM and efforts to do
120 well-publicized special-case workloads).
122 "fallow" hypervisor-owned RAM to not only be "time-shared" between multiple
124 optimize RAM utilization.  And when guest OS's are induced to surrender
125 underutilized RAM (e.g. with "selfballooning"), sudden unexpected
127 to be swapped to and from hypervisor RAM (if overall host system memory
145 CPU overhead is still negligible -- and since every frontswap fail
146 precedes a swap page write-to-disk, the system is highly likely
175 Whenever a swap-device is swapon'd frontswap_init() is called,
183 have room, frontswap_store returns -1 and the kernel swaps the page
194 When the swap subsystem needs to swap-in a page (swap_readpage()),
198 the swap-in is complete.  If not, the normal swap-in code is
208   or maybe swap-over-nbd/NFS)?
229 that are inappropriate for a RAM-oriented device including delaying
238 Similarly, a KVM guest-side implementation could do in-guest compression
243 choose to accept pages only until host-swapping might be imminent,
265 is non-compressible and so would take the entire 4K.  But the backend
274 When the (non-frontswap) swap subsystem swaps out a page to a real
275 swap device, that page is only taking up low-value pre-allocated disk
278 routine allows code outside of the swap subsystem to force pages out
279 of the memory managed by frontswap and back into kernel-addressable memory.
287 The frontswap code depends on some swap-subsystem-internal data