Lines Matching +full:d +full:- +full:cache +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,
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
145 CPU overhead is still negligible -- and since every frontswap fail
146 precedes a swap page write-to-disk, the system is highly likely
152 device that is swapon'd.  This is added to the EIGHT bits (which
154 for every swap page for every swap device that is swapon'd.  (Hugh
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)?
214 assumes a swap device is fixed size and any page in it is linearly
229 that are inappropriate for a RAM-oriented device including delaying
238 Similarly, a KVM guest-side implementation could do in-guest compression
243 choose to accept pages only until host-swapping might be imminent,
249 implemented as a "shadow" to every swapon'd device with the potential
252 that frontswap cannot contain more pages than the total of swapon'd
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