From: Gregory Haskins <ghaskins@novell.com>
To: Davide Libenzi <davidel@xmailserver.org>
Cc: kvm@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
avi@redhat.com
Subject: Re: [KVM PATCH 2/3] eventfd: add a notifier mechanism
Date: Thu, 23 Apr 2009 12:46:48 -0400 [thread overview]
Message-ID: <49F09B78.7000403@novell.com> (raw)
In-Reply-To: <alpine.DEB.1.10.0904230922180.18603@makko.or.mcafeemobile.com>
[-- Attachment #1: Type: text/plain, Size: 1592 bytes --]
Davide Libenzi wrote:
> On Thu, 23 Apr 2009, Gregory Haskins wrote:
>
>
>> This allows synchronous notifications to register with the eventfd
>> infrastructure. Unlike traditional vfs based eventfd readers, notifiees
>> do not implictly clear the counter on reception. However, the clearing
>> is primarily important to allowing threads to block waiting for events
>> anyway, so its an acceptable trade-off since blocking doesn't apply to
>> notifiers.
>>
>
> Do you really need to add a notifier? Eventfd already has a wait queue,
> and we support callback-based wakeups, so is there any reason we shouldn't
> use those and rely on the already existing wakeups?
>
Well, IIUC the issue is that a wait queue implies that you are in fact
waiting...which we may not. :)
The target in this particular application with kvm-irqfd is a vcpu
context, which *may* be sleeping in something like a HLT, but it also
could be in a number of other states such as non-root (guest) mode, it
could be running in the kernel, it could be up in userspace, etc.
That said: I am not married to the concept that this has to be a
notifier callback, but I do want to be able to meet the target
application. So if there is some way to do that within the existing
wait-queue contstruct, I am open to suggestions.
Thanks Davide,
-Greg
>
>
> - Davide
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 266 bytes --]
next prev parent reply other threads:[~2009-04-23 16:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-23 15:14 [KVM PATCH 0/3] irqfd Gregory Haskins
2009-04-23 15:14 ` [KVM PATCH 1/3] eventfd: export fget and signal interfaces for module use Gregory Haskins
2009-04-23 15:14 ` [KVM PATCH 2/3] eventfd: add a notifier mechanism Gregory Haskins
2009-04-23 16:23 ` Davide Libenzi
2009-04-23 16:46 ` Gregory Haskins [this message]
2009-04-23 22:03 ` Davide Libenzi
2009-04-23 22:12 ` Gregory Haskins
2009-04-24 2:43 ` Davide Libenzi
2009-04-24 4:11 ` Gregory Haskins
2009-04-24 16:13 ` Davide Libenzi
2009-04-24 16:29 ` Gregory Haskins
2009-04-23 15:14 ` [KVM PATCH 3/3] kvm: add support for irqfd via eventfd-notification interface Gregory Haskins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49F09B78.7000403@novell.com \
--to=ghaskins@novell.com \
--cc=avi@redhat.com \
--cc=davidel@xmailserver.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.