Documentation/mm/frontswap.rst

   1 =========
   2 Frontswap
   3 =========
   4
   5 Frontswap provides a "transcendent memory" interface for swap pages.
   6 In some environments, dramatic performance savings may be obtained because
   7 swapped pages are saved in RAM (or a RAM-like device) instead of a swap disk.
   8
   9 .. _Transcendent memory in a nutshell: https://lwn.net/Articles/454795/
  10
  11 Frontswap is so named because it can be thought of as the opposite of
  12 a "backing" store for a swap device.  The storage is assumed to be
  13 a synchronous concurrency-safe page-oriented "pseudo-RAM device" conforming
  14 to the requirements of transcendent memory (such as Xen's "tmem", or
  15 in-kernel compressed memory, aka "zcache", or future RAM-like devices);
  16 this pseudo-RAM device is not directly accessible or addressable by the
  17 kernel and is of unknown and possibly time-varying size.  The driver
  18 links itself to frontswap by calling frontswap_register_ops to set the
  19 frontswap_ops funcs appropriately and the functions it provides must
  20 conform to certain policies as follows:
  21
  22 An "init" prepares the device to receive frontswap pages associated
  23 with the specified swap device number (aka "type").  A "store" will
  24 copy the page to transcendent memory and associate it with the type and
  25 offset associated with the page. A "load" will copy the page, if found,
  26 from transcendent memory into kernel memory, but will NOT remove the page
  27 from transcendent memory.  An "invalidate_page" will remove the page
  28 from transcendent memory and an "invalidate_area" will remove ALL pages
  29 associated with the swap type (e.g., like swapoff) and notify the "device"
  30 to refuse further stores with that swap type.
  31
  32 Once a page is successfully stored, a matching load on the page will normally
  33 succeed.  So when the kernel finds itself in a situation where it needs
  34 to swap out a page, it first attempts to use frontswap.  If the store returns
  35 success, the data has been successfully saved to transcendent memory and
  36 a disk write and, if the data is later read back, a disk read are avoided.
  37 If a store returns failure, transcendent memory has rejected the data, and the
  38 page can be written to swap as usual.
  39
  40 Note that if a page is stored and the page already exists in transcendent memory
  41 (a "duplicate" store), either the store succeeds and the data is overwritten,
  42 or the store fails AND the page is invalidated.  This ensures stale data may
  43 never be obtained from frontswap.
  44
  45 If properly configured, monitoring of frontswap is done via debugfs in
  46 the `/sys/kernel/debug/frontswap` directory.  The effectiveness of
  47 frontswap can be measured (across all swap devices) with:
  48
  49 ``failed_stores``
  50         how many store attempts have failed
  51
  52 ``loads``
  53         how many loads were attempted (all should succeed)
  54
  55 ``succ_stores``
  56         how many store attempts have succeeded
  57
  58 ``invalidates``
  59         how many invalidates were attempted
  60
  61 A backend implementation may provide additional metrics.
  62
  63 FAQ
  64 ===
  65
  66 * Where's the value?
  67
  68 When a workload starts swapping, performance falls through the floor.
  69 Frontswap significantly increases performance in many such workloads by
  70 providing a clean, dynamic interface to read and write swap pages to
  71 "transcendent memory" that is otherwise not directly addressable to the kernel.
  72 This interface is ideal when data is transformed to a different form
  73 and size (such as with compression) or secretly moved (as might be
  74 useful for write-balancing for some RAM-like devices).  Swap pages (and
  75 evicted page-cache pages) are a great use for this kind of slower-than-RAM-
  76 but-much-faster-than-disk "pseudo-RAM device".
  77
  78 Frontswap with a fairly small impact on the kernel,
  79 provides a huge amount of flexibility for more dynamic, flexible RAM
  80 utilization in various system configurations:
  81
  82 In the single kernel case, aka "zcache", pages are compressed and
  83 stored in local memory, thus increasing the total anonymous pages
  84 that can be safely kept in RAM.  Zcache essentially trades off CPU
  85 cycles used in compression/decompression for better memory utilization.
  86 Benchmarks have shown little or no impact when memory pressure is
  87 low while providing a significant performance improvement (25%+)
  88 on some workloads under high memory pressure.
  89
  90 "RAMster" builds on zcache by adding "peer-to-peer" transcendent memory
  91 support for clustered systems.  Frontswap pages are locally compressed
  92 as in zcache, but then "remotified" to another system's RAM.  This
  93 allows RAM to be dynamically load-balanced back-and-forth as needed,
  94 i.e. when system A is overcommitted, it can swap to system B, and
  95 vice versa.  RAMster can also be configured as a memory server so
  96 many servers in a cluster can swap, dynamically as needed, to a single
  97 server configured with a large amount of RAM... without pre-configuring
  98 how much of the RAM is available for each of the clients!
  99
 100 In the virtual case, the whole point of virtualization is to statistically
 101 multiplex physical resources across the varying demands of multiple
 102 virtual machines.  This is really hard to do with RAM and efforts to do
 103 it well with no kernel changes have essentially failed (except in some
 104 well-publicized special-case workloads).
 105 Specifically, the Xen Transcendent Memory backend allows otherwise
 106 "fallow" hypervisor-owned RAM to not only be "time-shared" between multiple
 107 virtual machines, but the pages can be compressed and deduplicated to
 108 optimize RAM utilization.  And when guest OS's are induced to surrender
 109 underutilized RAM (e.g. with "selfballooning"), sudden unexpected
 110 memory pressure may result in swapping; frontswap allows those pages
 111 to be swapped to and from hypervisor RAM (if overall host system memory
 112 conditions allow), thus mitigating the potentially awful performance impact
 113 of unplanned swapping.
 114
 115 A KVM implementation is underway and has been RFC'ed to lkml.  And,
 116 using frontswap, investigation is also underway on the use of NVM as
 117 a memory extension technology.
 118
 119 * Sure there may be performance advantages in some situations, but
 120   what's the space/time overhead of frontswap?
 121
 122 If CONFIG_FRONTSWAP is disabled, every frontswap hook compiles into
 123 nothingness and the only overhead is a few extra bytes per swapon'ed
 124 swap device.  If CONFIG_FRONTSWAP is enabled but no frontswap "backend"
 125 registers, there is one extra global variable compared to zero for
 126 every swap page read or written.  If CONFIG_FRONTSWAP is enabled
 127 AND a frontswap backend registers AND the backend fails every "store"
 128 request (i.e. provides no memory despite claiming it might),
 129 CPU overhead is still negligible -- and since every frontswap fail
 130 precedes a swap page write-to-disk, the system is highly likely
 131 to be I/O bound and using a small fraction of a percent of a CPU
 132 will be irrelevant anyway.
 133
 134 As for space, if CONFIG_FRONTSWAP is enabled AND a frontswap backend
 135 registers, one bit is allocated for every swap page for every swap
 136 device that is swapon'd.  This is added to the EIGHT bits (which
 137 was sixteen until about 2.6.34) that the kernel already allocates
 138 for every swap page for every swap device that is swapon'd.  (Hugh
 139 Dickins has observed that frontswap could probably steal one of
 140 the existing eight bits, but let's worry about that minor optimization
 141 later.)  For very large swap disks (which are rare) on a standard
 142 4K pagesize, this is 1MB per 32GB swap.
 143
 144 When swap pages are stored in transcendent memory instead of written
 145 out to disk, there is a side effect that this may create more memory
 146 pressure that can potentially outweigh the other advantages.  A
 147 backend, such as zcache, must implement policies to carefully (but
 148 dynamically) manage memory limits to ensure this doesn't happen.
 149
 150 * OK, how about a quick overview of what this frontswap patch does
 151   in terms that a kernel hacker can grok?
 152
 153 Let's assume that a frontswap "backend" has registered during
 154 kernel initialization; this registration indicates that this
 155 frontswap backend has access to some "memory" that is not directly
 156 accessible by the kernel.  Exactly how much memory it provides is
 157 entirely dynamic and random.
 158
 159 Whenever a swap-device is swapon'd frontswap_init() is called,
 160 passing the swap device number (aka "type") as a parameter.
 161 This notifies frontswap to expect attempts to "store" swap pages
 162 associated with that number.
 163
 164 Whenever the swap subsystem is readying a page to write to a swap
 165 device (c.f swap_writepage()), frontswap_store is called.  Frontswap
 166 consults with the frontswap backend and if the backend says it does NOT
 167 have room, frontswap_store returns -1 and the kernel swaps the page
 168 to the swap device as normal.  Note that the response from the frontswap
 169 backend is unpredictable to the kernel; it may choose to never accept a
 170 page, it could accept every ninth page, or it might accept every
 171 page.  But if the backend does accept a page, the data from the page
 172 has already been copied and associated with the type and offset,
 173 and the backend guarantees the persistence of the data.  In this case,
 174 frontswap sets a bit in the "frontswap_map" for the swap device
 175 corresponding to the page offset on the swap device to which it would
 176 otherwise have written the data.
 177
 178 When the swap subsystem needs to swap-in a page (swap_readpage()),
 179 it first calls frontswap_load() which checks the frontswap_map to
 180 see if the page was earlier accepted by the frontswap backend.  If
 181 it was, the page of data is filled from the frontswap backend and
 182 the swap-in is complete.  If not, the normal swap-in code is
 183 executed to obtain the page of data from the real swap device.
 184
 185 So every time the frontswap backend accepts a page, a swap device read
 186 and (potentially) a swap device write are replaced by a "frontswap backend
 187 store" and (possibly) a "frontswap backend loads", which are presumably much
 188 faster.
 189
 190 * Can't frontswap be configured as a "special" swap device that is
 191   just higher priority than any real swap device (e.g. like zswap,
 192   or maybe swap-over-nbd/NFS)?
 193
 194 No.  First, the existing swap subsystem doesn't allow for any kind of
 195 swap hierarchy.  Perhaps it could be rewritten to accommodate a hierarchy,
 196 but this would require fairly drastic changes.  Even if it were
 197 rewritten, the existing swap subsystem uses the block I/O layer which
 198 assumes a swap device is fixed size and any page in it is linearly
 199 addressable.  Frontswap barely touches the existing swap subsystem,
 200 and works around the constraints of the block I/O subsystem to provide
 201 a great deal of flexibility and dynamicity.
 202
 203 For example, the acceptance of any swap page by the frontswap backend is
 204 entirely unpredictable. This is critical to the definition of frontswap
 205 backends because it grants completely dynamic discretion to the
 206 backend.  In zcache, one cannot know a priori how compressible a page is.
 207 "Poorly" compressible pages can be rejected, and "poorly" can itself be
 208 defined dynamically depending on current memory constraints.
 209
 210 Further, frontswap is entirely synchronous whereas a real swap
 211 device is, by definition, asynchronous and uses block I/O.  The
 212 block I/O layer is not only unnecessary, but may perform "optimizations"
 213 that are inappropriate for a RAM-oriented device including delaying
 214 the write of some pages for a significant amount of time.  Synchrony is
 215 required to ensure the dynamicity of the backend and to avoid thorny race
 216 conditions that would unnecessarily and greatly complicate frontswap
 217 and/or the block I/O subsystem.  That said, only the initial "store"
 218 and "load" operations need be synchronous.  A separate asynchronous thread
 219 is free to manipulate the pages stored by frontswap.  For example,
 220 the "remotification" thread in RAMster uses standard asynchronous
 221 kernel sockets to move compressed frontswap pages to a remote machine.
 222 Similarly, a KVM guest-side implementation could do in-guest compression
 223 and use "batched" hypercalls.
 224
 225 In a virtualized environment, the dynamicity allows the hypervisor
 226 (or host OS) to do "intelligent overcommit".  For example, it can
 227 choose to accept pages only until host-swapping might be imminent,
 228 then force guests to do their own swapping.
 229
 230 There is a downside to the transcendent memory specifications for
 231 frontswap:  Since any "store" might fail, there must always be a real
 232 slot on a real swap device to swap the page.  Thus frontswap must be
 233 implemented as a "shadow" to every swapon'd device with the potential
 234 capability of holding every page that the swap device might have held
 235 and the possibility that it might hold no pages at all.  This means
 236 that frontswap cannot contain more pages than the total of swapon'd
 237 swap devices.  For example, if NO swap device is configured on some
 238 installation, frontswap is useless.  Swapless portable devices
 239 can still use frontswap but a backend for such devices must configure
 240 some kind of "ghost" swap device and ensure that it is never used.
 241
 242 * Why this weird definition about "duplicate stores"?  If a page
 243   has been previously successfully stored, can't it always be
 244   successfully overwritten?
 245
 246 Nearly always it can, but no, sometimes it cannot.  Consider an example
 247 where data is compressed and the original 4K page has been compressed
 248 to 1K.  Now an attempt is made to overwrite the page with data that
 249 is non-compressible and so would take the entire 4K.  But the backend
 250 has no more space.  In this case, the store must be rejected.  Whenever
 251 frontswap rejects a store that would overwrite, it also must invalidate
 252 the old data and ensure that it is no longer accessible.  Since the
 253 swap subsystem then writes the new data to the read swap device,
 254 this is the correct course of action to ensure coherency.
 255
 256 * Why does the frontswap patch create the new include file swapfile.h?
 257
 258 The frontswap code depends on some swap-subsystem-internal data
 259 structures that have, over the years, moved back and forth between
 260 static and global.  This seemed a reasonable compromise:  Define
 261 them as global but declare them in a new include file that isn't
 262 included by the large number of source files that include swap.h.
 263
 264 Dan Magenheimer, last updated April 9, 2012