RE: [PATCH V2 0/4] Frontswap (was Transcendent Memory): overview

[Dan Magenheimer]

> From: Nitin Gupta [mailto:ngupta@xxxxxxxxxx]

> frontswap is a particular use case of zram disks. However, we still
> need to work on some issues with zram:
>  - zram cannot return write/put failures for arbitrary pages. OTOH,
> frontswap can consult host before every put and may forward pages to
> in-guest swap device when put fails.
>  - When a swap slot is freed, the notification from guest does
> not reach zram device(s) as exported from host. OTOH, frontswap calls
> frontswap_flush() which frees corresponding page from host memory.
>  - Being a block device, it is potentially slower than frontswap
> approach. But being a generic device, its useful for all kinds
> of guest OS (including windows etc).

Hi Nitin --

This is a good list (not sure offhand it is complete or not) of
the key differences between zram and frontswap.  Unless/until
zram solves each of these issues -- which are critical to the
primary objective of frontswap (namely intelligent overcommit) --
I simply can't agree that frontswap is a particular use case
of zram.  Zram is just batched asynchronous I/O to a fixed-size
device with a bonus of on-the-fly compression.  Cool, yes.
Useful, yes.  Useful in some cases in a virtualized environment,
yes.  But a superset/replacement of frontswap, no.

> Yes, zram cannot return write/put failure for arbitrary pages but other
> than that what additional benefits does frontswap bring? Even with
> frontswap,
> whatever pages are once given out to hypervisor just stay there till
> guest
> reads them back. Unlike cleancache, you cannot free them at any point.
> So,
> it does not seem anyway more flexible than zram.

The flexibility is that the hypervisor can make admittance
decisions on each individual page... this is exactly what
allows for intelligent overcommit.  Since the pages "just
stay there until the guest reads them back", the hypervisor
must be very careful about which and how many pages it accepts
and the admittance decisions must be very dynamic, depending
on a lot of factors not visible to any individual guest
and not timely enough to be determined by the asynchronous
"backend I/O" subsystem of a host or dom0.

Thanks,
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/