> 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, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href