On 04/27/2010 11:29 AM, Dan Magenheimer wrote:
OK, so on the one hand, you think that the proposed synchronous interface for frontswap is insufficiently extensible for other uses (presumably including KVM). On the other hand, you agree that using the existing I/O subsystem is unnecessarily heavyweight. On the third hand, Nitin has answered your questions and spent a good part of three years finding that extending the existing swap interface to efficiently support swap-to-pseudo-RAM requires some kind of in-kernel notification mechanism to which Linus has already objected. So you are instead proposing some new guest-to-host asynchronous notification mechanism that doesn't use the existing bio mechanism (and so presumably not irqs),
(any notification mechanism has to use irqs if it exits the guest)
imitates or can utilize a dma engine, and uses less cpu cycles than copying pages. AND, for long-term maintainability, you'd like to avoid creating a new guest-host API that does all this, even one that is as simple and lightweight as the proposed frontswap hooks. Does that summarize your objection well?
No. Adding a new async API that parallels the block layer would be madness. My first preference would be to completely avoid new APIs. I think that would work for swap-to-hypervisor but probably not for compcache. Second preference is the synchronous API, third is a new async API.
-- error compiling committee.c: too many arguments to function -- 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>