Lines Matching full:swap

7 Frontswap provides a "transcendent memory" interface for swap pages.
9 swapped pages are saved in RAM (or a RAM-like device) instead of a swap disk.
20 a "backing" store for a swap device. The storage is assumed to be
31 with the specified swap device number (aka "type"). A "store" will
37 associated with the swap type (e.g., like swapoff) and notify the "device"
38 to refuse further stores with that swap type.
42 to swap out a page, it first attempts to use frontswap. If the store returns
46 page can be written to swap as usual.
50 in swap device writes is lost (and also a non-trivial performance advantage)
61 frontswap can be measured (across all swap devices) with:
84 providing a clean, dynamic interface to read and write swap pages to
88 useful for write-balancing for some RAM-like devices). Swap pages (and
110 i.e. when system A is overcommitted, it can swap to system B, and
112 many servers in a cluster can swap, dynamically as needed, to a single
140 swap device. If CONFIG_FRONTSWAP is enabled but no frontswap "backend"
142 every swap page read or written. If CONFIG_FRONTSWAP is enabled
146 precedes a swap page write-to-disk, the system is highly likely
151 registers, one bit is allocated for every swap page for every swap
154 for every swap page for every swap device that is swapon'd. (Hugh
157 later.) For very large swap disks (which are rare) on a standard
158 4K pagesize, this is 1MB per 32GB swap.
160 When swap pages are stored in transcendent memory instead of written
175 Whenever a swap-device is swapon'd frontswap_init() is called,
176 passing the swap device number (aka "type") as a parameter.
177 This notifies frontswap to expect attempts to "store" swap pages
180 Whenever the swap subsystem is readying a page to write to a swap
184 to the swap device as normal. Note that the response from the frontswap
190 frontswap sets a bit in the "frontswap_map" for the swap device
191 corresponding to the page offset on the swap device to which it would
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
199 executed to obtain the page of data from the real swap device.
201 So every time the frontswap backend accepts a page, a swap device read
202 and (potentially) a swap device write are replaced by a "frontswap backend
206 * Can't frontswap be configured as a "special" swap device that is
207 just higher priority than any real swap device (e.g. like zswap,
208 or maybe swap-over-nbd/NFS)?
210 No. First, the existing swap subsystem doesn't allow for any kind of
211 swap hierarchy. Perhaps it could be rewritten to accommodate a hierarchy,
213 rewritten, the existing swap subsystem uses the block I/O layer which
214 assumes a swap device is fixed size and any page in it is linearly
215 addressable. Frontswap barely touches the existing swap subsystem,
219 For example, the acceptance of any swap page by the frontswap backend is
226 Further, frontswap is entirely synchronous whereas a real swap
248 slot on a real swap device to swap the page. Thus frontswap must be
250 capability of holding every page that the swap device might have held
253 swap devices. For example, if NO swap device is configured on some
256 some kind of "ghost" swap device and ensure that it is never used.
269 swap subsystem then writes the new data to the read swap device,
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
287 The frontswap code depends on some swap-subsystem-internal data
291 included by the large number of source files that include swap.h.