Davide Libenzi wrote:
> On Thu, 18 Jun 2009, Gregory Haskins wrote:
>
>>
>> But the fact is: I do not see any way to actually use your referenceless
>> POLLHUP release code in a race free way without doing something like I
>> propose in 3/4, 4/4. Lets keep the discussion focused on that for now,
Davide Libenzi wrote:
> On Thu, 18 Jun 2009, Gregory Haskins wrote:
>
>
>> Davide Libenzi wrote:
>>
>>> On Thu, 18 Jun 2009, Gregory Haskins wrote:
>>>
>>>
>>>
Actually there is only one (the tx-thread) aside from the eventfd
imposed workqueue one. Incidentally, I would
On Thu, 18 Jun 2009, Gregory Haskins wrote:
> Davide Libenzi wrote:
> > On Thu, 18 Jun 2009, Gregory Haskins wrote:
> >
> >
> >> Actually there is only one (the tx-thread) aside from the eventfd
> >> imposed workqueue one. Incidentally, I would love to get rid of the
> >> other thread too, so
Davide Libenzi wrote:
> On Thu, 18 Jun 2009, Gregory Haskins wrote:
>
>
>> Actually there is only one (the tx-thread) aside from the eventfd
>> imposed workqueue one. Incidentally, I would love to get rid of the
>> other thread too, so I am not just picking on eventfd ;). The other is
>> a lot
On Thu, 18 Jun 2009, Michael S. Tsirkin wrote:
> On Wed, Jun 17, 2009 at 04:21:19PM -0700, Davide Libenzi wrote:
> > The interface is just ugly IMO. You have eventfd_signal() that can sleep,
> > or not, depending on the registered ->signal() function implementations.
> > This is pretty bad, a lot
On Thu, 18 Jun 2009, Gregory Haskins wrote:
> Actually there is only one (the tx-thread) aside from the eventfd
> imposed workqueue one. Incidentally, I would love to get rid of the
> other thread too, so I am not just picking on eventfd ;). The other is
> a lot harder since it has to update the
Davide Libenzi wrote:
> On Wed, 17 Jun 2009, Gregory Haskins wrote:
>
>
>> I am not clear on what you are asking here. So in case this was a
>> sincere question on how things work, here is a highlight of the typical
>> flow of a packet that ingresses on a physical adapter and routes to KVM
>> v
Avi Kivity wrote:
> On 06/16/2009 05:40 PM, Gregory Haskins wrote:
>>
>> Something else to consider: For iosignalfd, we can assume we will
>> always be called from vcpu process context so we might not really need
>> official affirmation from the system. For irqfd, we cannot predict who
>> may be
On 06/16/2009 05:40 PM, Gregory Haskins wrote:
Something else to consider: For iosignalfd, we can assume we will
always be called from vcpu process context so we might not really need
official affirmation from the system. For irqfd, we cannot predict who
may be injecting the interrupt (for ins
On Wed, Jun 17, 2009 at 04:21:19PM -0700, Davide Libenzi wrote:
> The interface is just ugly IMO. You have eventfd_signal() that can sleep,
> or not, depending on the registered ->signal() function implementations.
> This is pretty bad, a lot worse than the theoretical us spent in the
> schedule_
On Wed, 17 Jun 2009, Gregory Haskins wrote:
> I am not clear on what you are asking here. So in case this was a
> sincere question on how things work, here is a highlight of the typical
> flow of a packet that ingresses on a physical adapter and routes to KVM
> via vbus.
>
> a) interrupt from et
Davide Libenzi wrote:
> On Wed, 17 Jun 2009, Gregory Haskins wrote:
>
>
>> Davide Libenzi wrote:
>>
>>
>>> How much the (possible, but not certain) kernel thread context switch time
>>> weighs in the overall KVM IRQ service time?
>>>
>>>
>> Generally each one is costing me about
On Wed, 17 Jun 2009, Gregory Haskins wrote:
> Davide Libenzi wrote:
>
> > How much the (possible, but not certain) kernel thread context switch time
> > weighs in the overall KVM IRQ service time?
> >
>
> Generally each one is costing me about 7us on average. For something
> like high-speed
Davide Libenzi wrote:
> On Wed, 17 Jun 2009, Gregory Haskins wrote:
>
>
>> Can you elaborate? I currently do not see how I could do the proposed
>> concept inside of irqfd while still using eventfd. Of course, that
>> would be possible if we fork irqfd from eventfd, and perhaps this is
>> wha
On Wed, 17 Jun 2009, Gregory Haskins wrote:
> Can you elaborate? I currently do not see how I could do the proposed
> concept inside of irqfd while still using eventfd. Of course, that
> would be possible if we fork irqfd from eventfd, and perhaps this is
> what you are proposing. As previousl
Hi Davide,
Davide Libenzi wrote:
> On Tue, 16 Jun 2009, Gregory Haskins wrote:
>
>
>> Davide Libenzi wrote:
>>
>>> On Tue, 16 Jun 2009, Gregory Haskins wrote:
>>>
>>>
>>>
Does this all make sense?
>>> This conversation has been *really* long, and I ha
On Tue, 16 Jun 2009, Gregory Haskins wrote:
> Davide Libenzi wrote:
> > On Tue, 16 Jun 2009, Gregory Haskins wrote:
> >
> >
> >> Does this all make sense?
> >>
> >
> > This conversation has been *really* long, and I haven't had time to look
> > at the patch yet. But looking at the amount
Michael S. Tsirkin wrote:
> On Wed, Jun 17, 2009 at 11:02:06AM -0400, Gregory Haskins wrote:
>
>> Michael S. Tsirkin wrote:
>>
>>> On Tue, Jun 16, 2009 at 02:09:38PM -0400, Gregory Haskins wrote:
>>>
>>>
> What do you mean by copy_to_user(other->mm) here? If you are going to
On Wed, Jun 17, 2009 at 11:02:06AM -0400, Gregory Haskins wrote:
> Michael S. Tsirkin wrote:
> > On Tue, Jun 16, 2009 at 02:09:38PM -0400, Gregory Haskins wrote:
> >
> >>> What do you mean by copy_to_user(other->mm) here? If you are going to
> >>> switch
> >>> to another mm, then I think curre
Michael S. Tsirkin wrote:
> On Tue, Jun 16, 2009 at 02:09:38PM -0400, Gregory Haskins wrote:
>
>>> What do you mean by copy_to_user(other->mm) here? If you are going to
>>> switch
>>> to another mm, then I think current->mm must be valid (I think it's not
>>> enough
>>> that you can sleep). S
On Tue, Jun 16, 2009 at 02:09:38PM -0400, Gregory Haskins wrote:
> > What do you mean by copy_to_user(other->mm) here? If you are going to
> > switch
> > to another mm, then I think current->mm must be valid (I think it's not
> > enough
> > that you can sleep). So preemptible() might not be enou
Michael S. Tsirkin wrote:
> On Tue, Jun 16, 2009 at 12:17:22PM -0400, Gregory Haskins wrote:
>
>>> Maybe I misunderstand what iosignalfd is - isn't it true that you get
>>> eventfd
>>> and kvm will signal that when guest performs io write to a specific
>>> address, and then drivers can get even
On Tue, Jun 16, 2009 at 12:17:22PM -0400, Gregory Haskins wrote:
> > Maybe I misunderstand what iosignalfd is - isn't it true that you get
> > eventfd
> > and kvm will signal that when guest performs io write to a specific
> > address, and then drivers can get eventfd and poll it to detect
> > the
Davide Libenzi wrote:
> On Tue, 16 Jun 2009, Gregory Haskins wrote:
>
>
>> Does this all make sense?
>>
>
> This conversation has been *really* long, and I haven't had time to look
> at the patch yet. But looking at the amount of changes, and the amount of
> even more changes talked in th
On Tue, 16 Jun 2009, Gregory Haskins wrote:
> Does this all make sense?
This conversation has been *really* long, and I haven't had time to look
at the patch yet. But looking at the amount of changes, and the amount of
even more changes talked in this thread, there's a very slim chance that
I'
Michael S. Tsirkin wrote:
> On Tue, Jun 16, 2009 at 11:20:18AM -0400, Gregory Haskins wrote:
>
> eventfd can't detect this state. But the callers know in what context
> they are.
> So the *caller* of eventfd_signal_task makes sure of this: if you are in
> a task,
> you can
On Tue, Jun 16, 2009 at 11:20:18AM -0400, Gregory Haskins wrote:
> >>> eventfd can't detect this state. But the callers know in what context
> >>> they are.
> >>> So the *caller* of eventfd_signal_task makes sure of this: if you are in
> >>> a task,
> >>> you can call eventfd_signal_task() if not
Michael S. Tsirkin wrote:
> On Tue, Jun 16, 2009 at 10:48:27AM -0400, Gregory Haskins wrote:
>
>> +static void _eventfd_notify(struct eventfd_ctx *ctx)
>> +{
>> +struct eventfd_notifier *en;
>> +int idx;
>> +
>> +idx = srcu_read_lock(&ctx->srcu);
>
On Tue, Jun 16, 2009 at 10:54:28AM -0400, Gregory Haskins wrote:
> > +static void _eventfd_notify(struct eventfd_ctx *ctx)
> > +{
> > + struct eventfd_notifier *en;
> > + int idx;
> > +
> > + idx = srcu_read_lock(&ctx->srcu);
> > +
> > + /*
>
On Tue, Jun 16, 2009 at 10:48:27AM -0400, Gregory Haskins wrote:
> +static void _eventfd_notify(struct eventfd_ctx *ctx)
> +{
> +struct eventfd_notifier *en;
> +int idx;
> +
> +idx = srcu_read_lock(&ctx->srcu);
> +
> +/*
>
Gregory Haskins wrote:
> Michael S. Tsirkin wrote:
>
>> On Tue, Jun 16, 2009 at 10:11:08AM -0400, Gregory Haskins wrote:
>>
>>
>>> Michael S. Tsirkin wrote:
>>>
>>>
On Mon, Jun 15, 2009 at 10:29:56PM -0400, Gregory Haskins wrote:
> i
Michael S. Tsirkin wrote:
> On Tue, Jun 16, 2009 at 10:11:08AM -0400, Gregory Haskins wrote:
>
>> Michael S. Tsirkin wrote:
>>
>>> On Mon, Jun 15, 2009 at 10:29:56PM -0400, Gregory Haskins wrote:
>>>
>>>
irqfd and its underlying implementation, eventfd, currently utilize
On Tue, Jun 16, 2009 at 10:40:55AM -0400, Gregory Haskins wrote:
> > This is ugly, isn't it? With CONFIG_PREEMPT=no preemptible() is always
> > false.
> >
> > Further, to do useful things it might not be enough that you can sleep:
> > with iofd you also want to access current task with e.g. copy f
Michael S. Tsirkin wrote:
> On Mon, Jun 15, 2009 at 10:29:56PM -0400, Gregory Haskins wrote:
>
>> irqfd and its underlying implementation, eventfd, currently utilize
>> the embedded wait-queue in eventfd for signal notification. The nice thing
>> about this design decision is that it re-uses th
On Tue, Jun 16, 2009 at 10:11:08AM -0400, Gregory Haskins wrote:
> Michael S. Tsirkin wrote:
> > On Mon, Jun 15, 2009 at 10:29:56PM -0400, Gregory Haskins wrote:
> >
> >> irqfd and its underlying implementation, eventfd, currently utilize
> >> the embedded wait-queue in eventfd for signal notifi
[Adding Ingo]
Gregory Haskins wrote:
> Michael S. Tsirkin wrote:
>
>> On Mon, Jun 15, 2009 at 10:29:56PM -0400, Gregory Haskins wrote:
>>
>>
>>> irqfd and its underlying implementation, eventfd, currently utilize
>>> the embedded wait-queue in eventfd for signal notification. The nice
Michael S. Tsirkin wrote:
> On Mon, Jun 15, 2009 at 10:29:56PM -0400, Gregory Haskins wrote:
>
>> irqfd and its underlying implementation, eventfd, currently utilize
>> the embedded wait-queue in eventfd for signal notification. The nice thing
>> about this design decision is that it re-uses th
Michael S. Tsirkin wrote:
> On Mon, Jun 15, 2009 at 10:29:56PM -0400, Gregory Haskins wrote:
>
>> irqfd and its underlying implementation, eventfd, currently utilize
>> the embedded wait-queue in eventfd for signal notification. The nice thing
>> about this design decision is that it re-uses th
On Mon, Jun 15, 2009 at 10:29:56PM -0400, Gregory Haskins wrote:
> irqfd and its underlying implementation, eventfd, currently utilize
> the embedded wait-queue in eventfd for signal notification. The nice thing
> about this design decision is that it re-uses the existing
> eventfd/wait-queue code
irqfd and its underlying implementation, eventfd, currently utilize
the embedded wait-queue in eventfd for signal notification. The nice thing
about this design decision is that it re-uses the existing
eventfd/wait-queue code and it generally works wellwith several
limitations.
One of the lim
40 matches
Mail list logo
