That sounds like a programming error, don't you think? Maybe
returning EINVAL is the right approach?
Maybe. I think I'd prefer to be permissive and queue as much as
possible, but it's not a strong preference. Returning EINVAL seems
ok, too.
- z
-
To unsubscribe from this list: send the
==> On Wed, 3 Jan 2007 10:50:06 -0800, Zach Brown <[EMAIL PROTECTED]> said:
Zach> The controversial part here happens when min_nr is larger than the
Zach> ring size. In that case I think we should consider min_nr to be
Zach> equal to the ring size. We'll return fewer events than userspace
Zach>
== On Wed, 3 Jan 2007 10:50:06 -0800, Zach Brown [EMAIL PROTECTED] said:
Zach The controversial part here happens when min_nr is larger than the
Zach ring size. In that case I think we should consider min_nr to be
Zach equal to the ring size. We'll return fewer events than userspace
Zach asked
That sounds like a programming error, don't you think? Maybe
returning EINVAL is the right approach?
Maybe. I think I'd prefer to be permissive and queue as much as
possible, but it's not a strong preference. Returning EINVAL seems
ok, too.
- z
-
To unsubscribe from this list: send the
On Jan 2, 2007, at 10:36 PM, Chen, Kenneth W wrote:
Zach Brown wrote on Tuesday, January 02, 2007 6:06 PM
In the example you
gave earlier, task with min_nr of 2 will be woken up after 4
completed
events.
I only gave 2 ios/events in that example.
Does that clear up the confusion?
It
On Jan 2, 2007, at 10:36 PM, Chen, Kenneth W wrote:
Zach Brown wrote on Tuesday, January 02, 2007 6:06 PM
In the example you
gave earlier, task with min_nr of 2 will be woken up after 4
completed
events.
I only gave 2 ios/events in that example.
Does that clear up the confusion?
It
Zach Brown wrote on Tuesday, January 02, 2007 6:06 PM
> > In the example you
> > gave earlier, task with min_nr of 2 will be woken up after 4 completed
> > events.
>
> I only gave 2 ios/events in that example.
>
> Does that clear up the confusion?
It occurs to me that people might not be aware
Zach Brown wrote on Tuesday, January 02, 2007 6:06 PM
> On Jan 2, 2007, at 5:50 PM, Chen, Kenneth W wrote:
> > Zach Brown wrote on Tuesday, January 02, 2007 5:24 PM
> >>> That is not possible because when multiple tasks waiting for
> >>> events, they
> >>> enter the wait queue in FIFO order,
On Jan 2, 2007, at 5:50 PM, Chen, Kenneth W wrote:
Zach Brown wrote on Tuesday, January 02, 2007 5:24 PM
That is not possible because when multiple tasks waiting for
events, they
enter the wait queue in FIFO order, prepare_to_wait_exclusive() does
__add_wait_queue_tail(). So first
Zach Brown wrote on Tuesday, January 02, 2007 5:24 PM
> > That is not possible because when multiple tasks waiting for
> > events, they
> > enter the wait queue in FIFO order, prepare_to_wait_exclusive() does
> > __add_wait_queue_tail(). So first io_getevents() with min_nr of 2
> > will be
That is not possible because when multiple tasks waiting for
events, they
enter the wait queue in FIFO order, prepare_to_wait_exclusive() does
__add_wait_queue_tail(). So first io_getevents() with min_nr of 2
will
be woken up when 2 ops completes.
So switch the order of the two sleepers
Zach Brown wrote on Tuesday, January 02, 2007 4:49 PM
> On Dec 29, 2006, at 6:31 PM, Chen, Kenneth W wrote:
> > This patch adds a wait condition to the wait queue and only wake-up
> > process when that condition meets. And this condition is added on a
> > per task base for handling multi-threaded
On Dec 29, 2006, at 6:31 PM, Chen, Kenneth W wrote:
The AIO wake-up notification from aio_complete is really inefficient
in current AIO implementation in the presence of process waiting in
io_getevents().
Yeah, it's a real deficiency. Thanks for taking a stab at it.
This patch adds a wait
On Dec 29, 2006, at 6:31 PM, Chen, Kenneth W wrote:
The AIO wake-up notification from aio_complete is really inefficient
in current AIO implementation in the presence of process waiting in
io_getevents().
Yeah, it's a real deficiency. Thanks for taking a stab at it.
This patch adds a wait
Zach Brown wrote on Tuesday, January 02, 2007 4:49 PM
On Dec 29, 2006, at 6:31 PM, Chen, Kenneth W wrote:
This patch adds a wait condition to the wait queue and only wake-up
process when that condition meets. And this condition is added on a
per task base for handling multi-threaded app
That is not possible because when multiple tasks waiting for
events, they
enter the wait queue in FIFO order, prepare_to_wait_exclusive() does
__add_wait_queue_tail(). So first io_getevents() with min_nr of 2
will
be woken up when 2 ops completes.
So switch the order of the two sleepers
Zach Brown wrote on Tuesday, January 02, 2007 5:24 PM
That is not possible because when multiple tasks waiting for
events, they
enter the wait queue in FIFO order, prepare_to_wait_exclusive() does
__add_wait_queue_tail(). So first io_getevents() with min_nr of 2
will be woken up
On Jan 2, 2007, at 5:50 PM, Chen, Kenneth W wrote:
Zach Brown wrote on Tuesday, January 02, 2007 5:24 PM
That is not possible because when multiple tasks waiting for
events, they
enter the wait queue in FIFO order, prepare_to_wait_exclusive() does
__add_wait_queue_tail(). So first
Zach Brown wrote on Tuesday, January 02, 2007 6:06 PM
On Jan 2, 2007, at 5:50 PM, Chen, Kenneth W wrote:
Zach Brown wrote on Tuesday, January 02, 2007 5:24 PM
That is not possible because when multiple tasks waiting for
events, they
enter the wait queue in FIFO order,
Zach Brown wrote on Tuesday, January 02, 2007 6:06 PM
In the example you
gave earlier, task with min_nr of 2 will be woken up after 4 completed
events.
I only gave 2 ios/events in that example.
Does that clear up the confusion?
It occurs to me that people might not be aware how
20 matches
Mail list logo
