Lines Matching refs:swap

1 Frontswap provides a "transcendent memory" interface for swap pages.
3 swapped pages are saved in RAM (or a RAM-like device) instead of a swap disk.
13 a "backing" store for a swap device.  The storage is assumed to be
24 with the specified swap device number (aka "type").  A "store" will
30 associated with the swap type (e.g., like swapoff) and notify the "device"
31 to refuse further stores with that swap type.
35 to swap out a page, it first attempts to use frontswap.  If the store returns
39 page can be written to swap as usual.
43 in swap device writes is lost (and also a non-trivial performance advantage)
54 frontswap can be measured (across all swap devices) with:
69 providing a clean, dynamic interface to read and write swap pages to
95 i.e. when system A is overcommitted, it can swap to system B, and
97 many servers in a cluster can swap, dynamically as needed, to a single
125 swap device.  If CONFIG_FRONTSWAP is enabled but no frontswap "backend"
127 every swap page read or written.  If CONFIG_FRONTSWAP is enabled
131 precedes a swap page write-to-disk, the system is highly likely
136 registers, one bit is allocated for every swap page for every swap
139 for every swap page for every swap device that is swapon'd.  (Hugh
142 later.)  For very large swap disks (which are rare) on a standard
143 4K pagesize, this is 1MB per 32GB swap.
145 When swap pages are stored in transcendent memory instead of written
160 Whenever a swap-device is swapon'd frontswap_init() is called,
161 passing the swap device number (aka "type") as a parameter.
162 This notifies frontswap to expect attempts to "store" swap pages
165 Whenever the swap subsystem is readying a page to write to a swap
169 to the swap device as normal.  Note that the response from the frontswap
175 frontswap sets a bit in the "frontswap_map" for the swap device
176 corresponding to the page offset on the swap device to which it would
179 When the swap subsystem needs to swap-in a page (swap_readpage()),
183 the swap-in is complete.  If not, the normal swap-in code is
184 executed to obtain the page of data from the real swap device.
186 So every time the frontswap backend accepts a page, a swap device read
187 and (potentially) a swap device write are replaced by a "frontswap backend
191 4) Can't frontswap be configured as a "special" swap device that is
192    just higher priority than any real swap device (e.g. like zswap,
193    or maybe swap-over-nbd/NFS)?
195 No.  First, the existing swap subsystem doesn't allow for any kind of
196 swap hierarchy.  Perhaps it could be rewritten to accommodate a hierarchy,
198 rewritten, the existing swap subsystem uses the block I/O layer which
199 assumes a swap device is fixed size and any page in it is linearly
200 addressable.  Frontswap barely touches the existing swap subsystem,
204 For example, the acceptance of any swap page by the frontswap backend is
211 Further, frontswap is entirely synchronous whereas a real swap
233 slot on a real swap device to swap the page.  Thus frontswap must be
235 capability of holding every page that the swap device might have held
238 swap devices.  For example, if NO swap device is configured on some
241 some kind of "ghost" swap device and ensure that it is never used.
254 swap subsystem then writes the new data to the read swap device,
259 When the (non-frontswap) swap subsystem swaps out a page to a real
260 swap device, that page is only taking up low-value pre-allocated disk
263 routine allows code outside of the swap subsystem to force pages out
272 The frontswap code depends on some swap-subsystem-internal data
276 included by the large number of source files that include swap.h.