Documentation/vm/frontswap.txt

   1 Frontswap provides a "transcendent memory" interface for swap pages.
   2 In some environments, dramatic performance savings may be obtained because
   3 swapped pages are saved in RAM (or a RAM-like device) instead of a swap disk.
   4
   5 Frontswap is so named because it can be thought of as the opposite of
   6 a "backing" store for a swap device.  The storage is assumed to be
   7 a synchronous concurrency-safe page-oriented "pseudo-RAM device" conforming
   8 to the requirements of transcendent memory (such as Xen's "tmem", or
   9 in-kernel compressed memory, aka "zcache", or future RAM-like devices);
  10 this pseudo-RAM device is not directly accessible or addressable by the
  11 kernel and is of unknown and possibly time-varying size.  The driver
  12 links itself to frontswap by calling frontswap_register_ops to set the
  13 frontswap_ops funcs appropriately and the functions it provides must
  14 conform to certain policies as follows:
  15
  16 An "init" prepares the device to receive frontswap pages associated
  17 with the specified swap device number (aka "type").  A "put_page" will
  18 copy the page to transcendent memory and associate it with the type and
  19 offset associated with the page. A "get_page" will copy the page, if found,
  20 from transcendent memory into kernel memory, but will NOT remove the page
  21 from from transcendent memory.  An "invalidate_page" will remove the page
  22 from transcendent memory and an "invalidate_area" will remove ALL pages
  23 associated with the swap type (e.g., like swapoff) and notify the "device"
  24 to refuse further puts with that swap type.
  25
  26 Once a page is successfully put, a matching get on the page will normally
  27 succeed.  So when the kernel finds itself in a situation where it needs
  28 to swap out a page, it first attempts to use frontswap.  If the put returns
  29 success, the data has been successfully saved to transcendent memory and
  30 a disk write and, if the data is later read back, a disk read are avoided.
  31 If a put returns failure, transcendent memory has rejected the data, and the
  32 page can be written to swap as usual.
  33
  34 Note that if a page is put and the page already exists in transcendent memory
  35 (a "duplicate" put), either the put succeeds and the data is overwritten,
  36 or the put fails AND the page is invalidated.  This ensures stale data may
  37 never be obtained from frontswap.
  38
  39 If properly configured, monitoring of frontswap is done via debugfs in
  40 the /sys/kernel/debug/frontswap directory.  The effectiveness of
  41 frontswap can be measured (across all swap devices) with:
  42
  43 failed_puts     - how many put attempts have failed
  44 gets            - how many gets were attempted (all should succeed)
  45 succ_puts       - how many put attempts have succeeded
  46 invalidates     - how many invalidates were attempted
  47
  48 A backend implementation may provide additional metrics.
  49
  50 FAQ
  51
  52 1) Where's the value?
  53
  54 When a workload starts swapping, performance falls through the floor.
  55 Frontswap significantly increases performance in many such workloads by
  56 providing a clean, dynamic interface to read and write swap pages to
  57 "transcendent memory" that is otherwise not directly addressable to the kernel.
  58 This interface is ideal when data is transformed to a different form
  59 and size (such as with compression) or secretly moved (as might be
  60 useful for write-balancing for some RAM-like devices).  Swap pages (and
  61 evicted page-cache pages) are a great use for this kind of slower-than-RAM-
  62 but-much-faster-than-disk "pseudo-RAM device" and the frontswap (and
  63 cleancache) interface to transcendent memory provides a nice way to read
  64 and write -- and indirectly "name" -- the pages.
  65
  66 In the virtual case, the whole point of virtualization is to statistically
  67 multiplex physical resources acrosst the varying demands of multiple
  68 virtual machines.  This is really hard to do with RAM and efforts to do
  69 it well with no kernel changes have essentially failed (except in some
  70 well-publicized special-case workloads).  Frontswap -- and cleancache --
  71 with a fairly small impact on the kernel, provides a huge amount
  72 of flexibility for more dynamic, flexible RAM multiplexing.
  73 Specifically, the Xen Transcendent Memory backend allows otherwise
  74 "fallow" hypervisor-owned RAM to not only be "time-shared" between multiple
  75 virtual machines, but the pages can be compressed and deduplicated to
  76 optimize RAM utilization.  And when guest OS's are induced to surrender
  77 underutilized RAM (e.g. with "self-ballooning"), sudden unexpected
  78 memory pressure may result in swapping; frontswap allows those pages
  79 to be swapped to and from hypervisor RAM if overall host system memory
  80 conditions allow.
  81
  82 2) Sure there may be performance advantages in some situations, but
  83    what's the space/time overhead of frontswap?
  84
  85 If CONFIG_FRONTSWAP is disabled, every frontswap hook compiles into
  86 nothingness and the only overhead is a few extra bytes per swapon'ed
  87 swap device.  If CONFIG_FRONTSWAP is enabled but no frontswap "backend"
  88 registers, there is one extra global variable compared to zero for
  89 every swap page read or written.  If CONFIG_FRONTSWAP is enabled
  90 AND a frontswap backend registers AND the backend fails every "put"
  91 request (i.e. provides no memory despite claiming it might),
  92 CPU overhead is still negligible -- and since every frontswap fail
  93 precedes a swap page write-to-disk, the system is highly likely
  94 to be I/O bound and using a small fraction of a percent of a CPU
  95 will be irrelevant anyway.
  96
  97 As for space, if CONFIG_FRONTSWAP is enabled AND a frontswap backend
  98 registers, one bit is allocated for every swap page for every swap
  99 device that is swapon'd.  This is added to the EIGHT bits (which
 100 was sixteen until about 2.6.34) that the kernel already allocates
 101 for every swap page for every swap device that is swapon'd.  (Hugh
 102 Dickins has observed that frontswap could probably steal one of
 103 the existing eight bits, but let's worry about that minor optimization
 104 later.)  For very large swap disks (which are rare) on a standard
 105 4K pagesize, this is 1MB per 32GB swap.
 106
 107 3) OK, how about a quick overview of what this frontswap patch does
 108    in terms that a kernel hacker can grok?
 109
 110 Let's assume that a frontswap "backend" has registered during
 111 kernel initialization; this registration indicates that this
 112 frontswap backend has access to some "memory" that is not directly
 113 accessible by the kernel.  Exactly how much memory it provides is
 114 entirely dynamic and random.
 115
 116 Whenever a swap-device is swapon'd frontswap_init() is called,
 117 passing the swap device number (aka "type") as a parameter.
 118 This notifies frontswap to expect attempts to "put" swap pages
 119 associated with that number.
 120
 121 Whenever the swap subsystem is readying a page to write to a swap
 122 device (c.f swap_writepage()), frontswap_put_page is called.  Frontswap
 123 consults with the frontswap backend and if the backend says it does NOT
 124 have room, frontswap_put_page returns -1 and the kernel swaps the page
 125 to the swap device as normal.  Note that the response from the frontswap
 126 backend is unpredictable to the kernel; it may choose to never accept a
 127 page, it could accept every ninth page, or it might accept every
 128 page.  But if the backend does accept a page, the data from the page
 129 has already been copied and associated with the type and offset,
 130 and the backend guarantees the persistence of the data.  In this case,
 131 frontswap sets a bit in the "frontswap_map" for the swap device
 132 corresponding to the page offset on the swap device to which it would
 133 otherwise have written the data.
 134
 135 When the swap subsystem needs to swap-in a page (swap_readpage()),
 136 it first calls frontswap_get_page() which checks the frontswap_map to
 137 see if the page was earlier accepted by the frontswap backend.  If
 138 it was, the page of data is filled from the frontswap backend and
 139 the swap-in is complete.  If not, the normal swap-in code is
 140 executed to obtain the page of data from the real swap device.
 141
 142 So every time the frontswap backend accepts a page, a swap device read
 143 and (potentially) a swap device write are replaced by a "frontswap backend
 144 put" and (possibly) a "frontswap backend get", which are presumably much
 145 faster.
 146
 147 4) Can't frontswap be configured as a "special" swap device that is
 148    just higher priority than any real swap device (e.g. like zswap)?
 149
 150 No.  Recall that acceptance of any swap page by the frontswap
 151 backend is entirely unpredictable. This is critical to the definition
 152 of frontswap because it grants completely dynamic discretion to the
 153 backend.  But since any "put" might fail, there must always be a real
 154 slot on a real swap device to swap the page.  Thus frontswap must be
 155 implemented as a "shadow" to every swapon'd device with the potential
 156 capability of holding every page that the swap device might have held
 157 and the possibility that it might hold no pages at all.
 158 On the downside, this also means that frontswap cannot contain more
 159 pages than the total of swapon'd swap devices.  For example, if NO
 160 swap device is configured on some installation, frontswap is useless.
 161
 162 Further, frontswap is entirely synchronous whereas a real swap
 163 device is, by definition, asynchronous and uses block I/O.  The
 164 block I/O layer is not only unnecessary, but may perform "optimizations"
 165 that are inappropriate for a RAM-oriented device including delaying
 166 the write of some pages for a significant amount of time.  Synchrony is
 167 required to ensure the dynamicity of the backend and to avoid thorny race
 168 conditions that would unnecessarily and greatly complicate frontswap
 169 and/or the block I/O subsystem.
 170
 171 In a virtualized environment, the dynamicity allows the hypervisor
 172 (or host OS) to do "intelligent overcommit".  For example, it can
 173 choose to accept pages only until host-swapping might be imminent,
 174 then force guests to do their own swapping.  In zcache, "poorly"
 175 compressible pages can be rejected, where "poorly" can itself be defined
 176 dynamically depending on current memory constraints.
 177
 178 5) Why this weird definition about "duplicate puts"?  If a page
 179    has been previously successfully put, can't it always be
 180    successfully overwritten?
 181
 182 Nearly always it can, but no, sometimes it cannot.  Consider an example
 183 where data is compressed and the original 4K page has been compressed
 184 to 1K.  Now an attempt is made to overwrite the page with data that
 185 is non-compressible and so would take the entire 4K.  But the backend
 186 has no more space.  In this case, the put must be rejected.  Whenever
 187 frontswap rejects a put that would overwrite, it also must invalidate
 188 the old data and ensure that it is no longer accessible.  Since the
 189 swap subsystem then writes the new data to the read swap device,
 190 this is the correct course of action to ensure coherency.
 191
 192 6) What is frontswap_shrink for?
 193
 194 When the (non-frontswap) swap subsystem swaps out a page to a real
 195 swap device, that page is only taking up low-value pre-allocated disk
 196 space.  But if frontswap has placed a page in transcendent memory, that
 197 page may be taking up valuable real estate.  The frontswap_shrink
 198 routine allows code outside of the swap subsystem (such as Xen tmem
 199 or zcache or some future tmem backend) to force pages out of the memory
 200 managed by frontswap and back into kernel-addressable memory.
 201
 202 7) Why does the frontswap patch create the new include file swapfile.h?
 203
 204 The frontswap code depends on some swap-subsystem-internal data
 205 structures that have, over the years, moved back and forth between
 206 static and global.  This seemed a reasonable compromise:  Define
 207 them as global but declare them in a new include file that isn't
 208 included by the large number of source files that include swap.h.
 209
 210 Dan Magenheimer, last updated September 12, 2011