Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 27 Apr 2010 12:21:09 +0300 | From | Avi Kivity <> | Subject | Re: Frontswap [PATCH 0/4] (was Transcendent Memory): overview |
| |
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
| ![\](/images/icornerr.gif) |