Hi! > > > Nevertheless, frontswap works great today with a bare-metal > > > hypervisor. I think it stands on its own merits, regardless > > > of one's vision of future SSD/memory technologies. > > > > Even when frontswapping to RAM on a bare metal hypervisor it makes > > sense > > to use an async API, in case you have a DMA engine on board. > > When pages are 2MB, this may be true. When pages are 4KB and > copied individually, it may take longer to program a DMA engine > than to just copy 4KB. > > But in any case, frontswap works fine on all existing machines > today. If/when most commodity CPUs have an asynchronous RAM DMA > engine, an asynchronous API may be appropriate. Or the existing > swap API might be appropriate. Or the synchronous frontswap API > may work fine too. Speculating further about non-existent > hardware that might exist in the (possibly far) future is irrelevant > to the proposed patch, which works today on all existing x86 hardware > and on shipping software. 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? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>