Lines Matching +full:i +full:- +full:cache +full:- +full:block +full:- +full:size

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
49 cache" by calling frontswap_writethrough().  In this mode, the reduction
50 in swap device writes is lost (and also a non-trivial performance advantage)
87 and size (such as with compression) or secretly moved (as might be
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,
106 "RAMster" builds on zcache by adding "peer-to-peer" transcendent memory
109 allows RAM to be dynamically load-balanced back-and-forth as needed,
110 i.e. when system A is overcommitted, it can swap to system B, and
113 server configured with a large amount of RAM... without pre-configuring
120 well-publicized special-case workloads).
122 "fallow" hypervisor-owned RAM to not only be "time-shared" between multiple
144 request (i.e. provides no memory despite claiming it might),
145 CPU overhead is still negligible -- and since every frontswap fail
146 precedes a swap page write-to-disk, the system is highly likely
147 to be I/O bound and using a small fraction of a percent of a CPU
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)?
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
216 and works around the constraints of the block I/O subsystem to provide
227 device is, by definition, asynchronous and uses block I/O.  The
228 block I/O layer is not only unnecessary, but may perform "optimizations"
229 that are inappropriate for a RAM-oriented device including delaying
233 and/or the block I/O subsystem.  That said, only the initial "store"
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
279 of the memory managed by frontswap and back into kernel-addressable memory.
287 The frontswap code depends on some swap-subsystem-internal data