On Wed, Jan 06, 2010 at 01:17:02PM -0800, Davide Libenzi wrote: > On Wed, 6 Jan 2010, Michael S. Tsirkin wrote: > > > I tried to explain, no? That patch was taking wait queue spinlock and > > was assuming that eventfd_read_ctx is called from a task that can block. > > KVM attaches its own poller so this is not a good fit for us. Hope this > > clarifies. > > > > > and yet again you managed to add an underscore at the beginning of the > > > API name, in an API set where there are no leading underscores. Even > > > if KVM does that for its own reasons, you should be able to fit your > > > naming "style" to the interface you're adding your droplets into. I > > > will post an eventfd_read_ctx() to Andrew ASAP. > > > > > > > > > > > > - Davide > > > > Sorry about the underscore - it's easy to fix but I won't bore you with > > more patch revisions before I understand what makes you unhappy. > > > > Before KVM starts creating workqueues and doing schedule_work calls just > > to work around the API, can we discuss this please? I am not hung on my > > patch, but could we have it work so that we can call eventfd_read_ctx > > from wait queue callback directly? > > The "read" needs to wake possible OUT waiters, *cannot* be done your way. Right. Now I see. Thanks! > On top of creating an interface which requires a lock, which noone can get > from the interface itself, since it's not exposed. I think here's how KVM gets it: the way it does is by calling poll with our own poll table, then in poll_queue_proc we get wait queue pointer, and we use the wait queue. Lock is in there :) > I could split the two and have a locked one, and an unlocked one, but that > looks shitty too (for the above reason). Yes, this will work. Thanks! > I thought you *already* do your own stuff from a work queue, why would you > need to read from IRQ context? > > > > - Davide This was just work around while interrupt delivery was using mutex locks, so we had a workqueue to work around that limitation. Now that it has been all switched to RCU, we'll be getting getting rid of this. -- MST -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
