From: Suparna Bhattacharya <suparna@in.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-aio@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH][2.6-mm] Avoid flushing AIO workqueue on cancel/exit
Date: Tue, 21 Oct 2003 16:57:13 +0530 [thread overview]
Message-ID: <20031021112713.GA4264@in.ibm.com> (raw)
In-Reply-To: <20031021035900.18040eee.akpm@osdl.org>
On Tue, Oct 21, 2003 at 03:59:00AM -0700, Andrew Morton wrote:
> Suparna Bhattacharya <suparna@in.ibm.com> wrote:
> >
> > When streaming AIO requests are in progress on multiple
> > io context's, flushing the AIO workqueue on i/o cancellation
> > or process exit could potentially end up waiting for a
> > long time as fresh requests from other active ioctx's keep
> > getting queued up.
>
> But flush_workqueue() will ignore any newly-added work requests:
>
> * This function will sample each workqueue's current insert_sequence number and
> * will sleep until the head sequence is greater than or equal to that. This
> * means that we sleep until all works which were queued on entry have been
> * handled, but we are not livelocked by new incoming ones.
True. I must have had an old version of workqueue.c in mind ... which
had a warning of that sort; I didn't realise that had been fixed.
Now that we have included the patch to splice the AIO runlist,
newer requests getting queued up on the ioctx shouldn't livelock us.
So yes this isn't strictly necessary. We still have one ioctx cancellation
waiting for ongoing retries on other ioctx's system wide to get done,
instead of just the io context being cancelled, but that's probably
not so bad. We can wait till that shows up as a real problem.
>
> Now, flush_workqueue() is potentially inefficient on SMP because it flushes
> each CPU's workqueue sequentially. But we can fix that in
> flush_workqueue() by converting it to a two-pass approach:
>
> a) gather each CPU's insert_sequence number into a local array[NR_CPUS]
>
> b) wait until each CPU's remove_sequence number exceeds the previously-gathered
> insert_sequence number.
>
Regards
Suparna
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-aio' in
> the body to majordomo@kvack.org. For more info on Linux AIO,
> see: http://www.kvack.org/aio/
> Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
--
Suparna Bhattacharya (suparna@in.ibm.com)
Linux Technology Center
IBM Software Labs, India
prev parent reply other threads:[~2003-10-21 11:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-21 10:25 [PATCH][2.6-mm] Avoid flushing AIO workqueue on cancel/exit Suparna Bhattacharya
2003-10-21 10:59 ` Andrew Morton
2003-10-21 11:27 ` Suparna Bhattacharya [this message]
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=20031021112713.GA4264@in.ibm.com \
--to=suparna@in.ibm.com \
--cc=akpm@osdl.org \
--cc=linux-aio@kvack.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.