On Mon, Jul 31, 2006 at 03:12:29PM -0700, Zach Brown wrote:
> [AIO] remove unused aio_run_iocbs()
>
> Nothing is calling the aio_run_iocbs() variant of *aio_run_*iocb*(). Let's try
> and make life just a little less complicated by getting rid of it.
Chris Mason's aio pipe patches used these to reduce the large
number of context switches he was observing when running pipetest.
Of course aio pipe support hasn't been merged into mainline so far, and hence
you could argue that we put these back in if/when we hit that problem. But why
not just put in a comment there for now to ease the confusion ... generally
I'd rather go a little slow in removing apparently unused code at this
point when we are churning things up again.
Regards
Suparna
>
> Signed-off-by: Zach Brown <[email protected]>
> ---
>
> fs/aio.c | 21 ++-------------------
> 1 file changed, 2 insertions(+), 19 deletions(-)
>
> Index: 2.6.18-rc3-trivialaio/fs/aio.c
> ===================================================================
> --- 2.6.18-rc3-trivialaio.orig/fs/aio.c
> +++ 2.6.18-rc3-trivialaio/fs/aio.c
> @@ -814,30 +814,13 @@ static void aio_queue_work(struct kioctx
> queue_delayed_work(aio_wq, &ctx->wq, timeout);
> }
>
> -
> /*
> - * aio_run_iocbs:
> + * aio_run_all_iocbs:
> * Process all pending retries queued on the ioctx
> - * run list.
> + * run list. It will retry until the list stays empty.
> * Assumes it is operating within the aio issuer's mm
> * context.
> */
> -static inline void aio_run_iocbs(struct kioctx *ctx)
> -{
> - int requeue;
> -
> - spin_lock_irq(&ctx->ctx_lock);
> -
> - requeue = __aio_run_iocbs(ctx);
> - spin_unlock_irq(&ctx->ctx_lock);
> - if (requeue)
> - aio_queue_work(ctx);
> -}
> -
> -/*
> - * just like aio_run_iocbs, but keeps running them until
> - * the list stays empty
> - */
> static inline void aio_run_all_iocbs(struct kioctx *ctx)
> {
> spin_lock_irq(&ctx->ctx_lock);
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-aio' in
> the body to [email protected]. For more info on Linux AIO,
> see: http://www.kvack.org/aio/
> Don't email: <a href=mailto:"[email protected]">[email protected]</a>
--
Suparna Bhattacharya ([email protected])
Linux Technology Center
IBM Software Lab, India
> Chris Mason's aio pipe patches used these to reduce the large
> number of context switches he was observing when running pipetest.
> Of course aio pipe support hasn't been merged into mainline so far, and hence
> you could argue that we put these back in if/when we hit that problem.
Yeah, and that's trivial.
> But why
> not just put in a comment there for now to ease the confusion ... generally
> I'd rather go a little slow in removing apparently unused code at this
> point when we are churning things up again.
The only thing slower than not removing it after *years* of not being
used would be to never remove it :)
So I don't see any value in keeping it, but I won't make a fight of it
either.
- z
On Tue, Aug 01, 2006 at 09:14:19AM -0700, Zach Brown wrote:
> > Chris Mason's aio pipe patches used these to reduce the large
> > number of context switches he was observing when running pipetest.
> > Of course aio pipe support hasn't been merged into mainline so far, and hence
> > you could argue that we put these back in if/when we hit that problem.
>
> Yeah, and that's trivial.
>
> > But why
> > not just put in a comment there for now to ease the confusion ... generally
> > I'd rather go a little slow in removing apparently unused code at this
> > point when we are churning things up again.
>
> The only thing slower than not removing it after *years* of not being
> used would be to never remove it :)
By slow, I meant having enough time between posting the RFC/patch and
its getting included in -mm or mainline. The AIO core code is tricky and
subtle in parts, so it is better to err on the side of caution during such
cleanups, at least give ourselves time to remember why something was there
in the first place. Especially now that there are several out-of-tree patches
under re-consideration.
>
> So I don't see any value in keeping it, but I won't make a fight of it
> either.
Its not a big deal either way in this particular case - possibly only
some redundant work eventually. And I think its already in -mm anyway.
I'm just raising the flag about the need to be very careful about cleanups
in this part of the code in general. Under such circumstances, I would
tend to look at it from the angle of "Is there a value in removing it ?"
rather than the other way around.
Regards
Suparna
>
> - z
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-aio' in
> the body to [email protected]. For more info on Linux AIO,
> see: http://www.kvack.org/aio/
> Don't email: <a href=mailto:"[email protected]">[email protected]</a>
--
Suparna Bhattacharya ([email protected])
Linux Technology Center
IBM Software Lab, India