From: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
To: "'Zach Brown'" <zach.brown@oracle.com>
Cc: "'Andrew Morton'" <akpm@osdl.org>, <linux-aio@kvack.org>,
<linux-kernel@vger.kernel.org>,
"'Benjamin LaHaise'" <bcrl@kvack.org>, <suparna@in.ibm.com>
Subject: RE: [patch] aio: add per task aio wait event condition
Date: Tue, 2 Jan 2007 17:50:53 -0800 [thread overview]
Message-ID: <000f01c72ed9$9a73cdd0$ff0da8c0@amr.corp.intel.com> (raw)
In-Reply-To: <122AE2A2-3807-42F0-AADF-7305D66CBCE5@oracle.com>
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 when 2 ops completes.
>
> So switch the order of the two sleepers in the example?
Not sure why that would be a problem though: whoever sleep first will
be woken up first.
> The point is that there's no way to guarantee that the head of the
> wait queue will be the lowest min_nr.
Before I challenge that semantics, I want to mention that in current
implementation, dribbling AIO events will be distributed in round robin
fashion to all pending tasks waiting in io_getevents. In the example you
gave earlier, task with min_nr of 2 will be woken up after 4 completed
events. I consider that as an undesirable behavior as well.
Going back to your counter argument, why do we need the lowest min_nr in
the head of the queue? These are tasks that shares one aio ctx and ioctx
is shareable only among threads. Any reason why round robin policy is
superior than FIFO? Also presumably, threads that shares ioctx should be
capable of handling events for the same ioctx.
>From wakeup order point of view, yes, tasks with lowest min_nr wakes up
first, but looking from io completion order, they are not. And these are
the source of excessive ctx switch.
next prev parent reply other threads:[~2007-01-03 1:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-30 2:31 Chen, Kenneth W
2007-01-03 0:49 ` Zach Brown
2007-01-03 1:16 ` Chen, Kenneth W
2007-01-03 1:23 ` Zach Brown
2007-01-03 1:50 ` Chen, Kenneth W [this message]
2007-01-03 2:06 ` Zach Brown
2007-01-03 2:32 ` Chen, Kenneth W
2007-01-03 6:36 ` Chen, Kenneth W
2007-01-03 18:50 ` Zach Brown
2007-02-01 21:46 ` Jeff Moyer
2007-02-01 22:21 ` Zach Brown
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='000f01c72ed9$9a73cdd0$ff0da8c0@amr.corp.intel.com' \
--to=kenneth.w.chen@intel.com \
--cc=akpm@osdl.org \
--cc=bcrl@kvack.org \
--cc=linux-aio@kvack.org \
--cc=linux-kernel@vger.kernel.org \
--cc=suparna@in.ibm.com \
--cc=zach.brown@oracle.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®