> Stop right here. Instead of improving existing swap api, you just > create one because it is less work. > > We do not want apis to cummulate; please just fix the existing one. > If we added all the apis that worked when proposed, we'd have > unmaintanable mess by about 1996. > > Why can't frontswap just use existing swap api? Hi Pavel! The existing swap API as it stands is inadequate for an efficient synchronous interface (e.g. for swapping to RAM). Both Nitin and I independently have found this to be true. But swap-to-RAM is very useful in some cases (swap-to-kernel-compressed-RAM and swap-to-hypervisor-RAM and maybe others) that were not even conceived many years ago at the time the existing swap API was designed for swap-to-disk. Swap-to-RAM can relieve memory pressure faster and more resource-efficient than swap-to-device but must assume that RAM available for swap-to-RAM is dynamic (not fixed in size). (And swap-to-SSD, when the SSD is an I/O device on an I/O bus is NOT the same as swap-to-RAM.) In my opinion, frontswap is NOT a new API, but the simplest possible extension of the existing swap API to allow for efficient swap-to-RAM. Avi's comments about a new API (as he explained later in the thread) refer to a new API between kernel and hypervisor, what is essentially the Transcendent Memory interface. Frontswap was separated from the tmem dependency to enable Nitin's swap-to-kernel-compressed-RAM and the possibility that there may be other interesting swap-to-RAM uses. Does this help? 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