Lines Matching refs:pages

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.
23 An "init" prepares the device to receive frontswap pages associated
29 from transcendent memory and an "invalidate_area" will remove ALL pages
45 store frontswap pages to more completely manage its memory usage.
69 providing a clean, dynamic interface to read and write swap pages to
73 useful for write-balancing for some RAM-like devices).  Swap pages (and
74 evicted page-cache pages) are a great use for this kind of slower-than-RAM-
77 and write -- and indirectly "name" -- the pages.
83 In the single kernel case, aka "zcache", pages are compressed and
84 stored in local memory, thus increasing the total anonymous pages
92 support for clustered systems.  Frontswap pages are locally compressed
108 virtual machines, but the pages can be compressed and deduplicated to
111 memory pressure may result in swapping; frontswap allows those pages
145 When swap pages are stored in transcendent memory instead of written
162 This notifies frontswap to expect attempts to "store" swap pages
208 "Poorly" compressible pages can be rejected, and "poorly" can itself be
215 the write of some pages for a significant amount of time.  Synchrony is
220 is free to manipulate the pages stored by frontswap.  For example,
222 kernel sockets to move compressed frontswap pages to a remote machine.
228 choose to accept pages only until host-swapping might be imminent,
236 and the possibility that it might hold no pages at all.  This means
237 that frontswap cannot contain more pages than the total of swapon'd
263 routine allows code outside of the swap subsystem to force pages out
266 to "repatriate" pages sent to a remote machine back to the local machine;