On 04/24/2010 11:57 PM, Avi Kivity wrote:
On 04/24/2010 04:49 AM, Nitin Gupta wrote:No: trim or discard is not useful. The problem is that we require a callback
Isn't that TRIM?I see. So why not implement this as an ordinary swap device, with aramzswap is exactly this: an ordinary swap device which stores every page
higher priority than the disk device? this way we reuse an API and keep
things asynchronous, instead of introducing a special purpose API.
in (compressed) memory and its enabled as highest priority swap.
Currently,
it stores these compressed chunks in guest memory itself but it is not
very
difficult to send these chunks out to host/hypervisor using virtio.
However, it suffers from unnecessary block I/O layer overhead and
requires
weird hooks in swap code, say to get notification when a swap slot is
freed.
_as soon as_ a page (swap slot) is freed. Otherwise, stale data quickly accumulates
in memory defeating the whole purpose of in-memory compressed swap devices (like ramzswap).
Increasing the frequency of discards is also not an option:
- Creating discard bio requests themselves need memory and these swap devices
come into picture only under low memory conditions.
- We need to regularly scan swap_map to issue these discards. Increasing discard
frequency also means more frequent scanning (which will still not be fast enough
for ramzswap needs).
Maybe we should optimize these overheads instead. Swap used to alwaysSpending lot of effort optimizing an overhead which can be completely avoided
be to slow devices, but swap-to-flash has the potential to make swap act
like an extension of RAM.
is probably not worth it.
Also, I think the choice of a synchronous style API for frontswap and cleancache
is justified as they want to send pages to host *RAM*. If you want to use other
devices like SSDs, then these should be just added as another swap device as
we do currently -- these should not be used as frontswap storage directly.