>
> Badari Pulavarty wrote:
> >
> > Andrew,
> >
> > >
> > > Thanks. Note that the old code (which seems to be a tiny bit faster,
> > > and used less CPU as well) has a significantly higher context switch
> > > rate. At a guess I'd say that it is more efficient at getting userspace
> > > up and running in response to IO completion.
> > >
> >
> > I my patch, I removed bio_list. So, I do all the processing of "bio"
> > in end_io() function, instead of postpone it to waiter. Do you think
> > this matters ?
>
> Ah. Yes, it matters.
>
> Running the completion in process context is nicer from an interrupt latency
> point of view. But the completion code also runs set_page_dirty(), which
> takes locks which are not interrupt-safe. Running set_page_dirty() from
> interrupt context can deadlock.
>
> So if it's convenient, yes, let's do the completion in process context.
> If not convenient then we'll need to find some way of running
> set_page_dirty() outside the interrupt handler.
>
> The set_page_dirty() is there to cover the case of direct-io into a
> mmapped region of another file. We need to tell the VM that the page
> has been changed, because the CPU's ptes don't know that. And we do
> have to run set_page_dirty() after the read IO has completed.
OK !! We have to find a way to do set_page_dirty() safely, I guess.
>
> The other thing we've lost is the BIO-pruning and recycling effect: the
> current direct-io code will reap BIOs while it is actually submitting
> them, so the peak consumption is kept under control. Plus there are
> cache-warmness issues. But without having a process there to do all this,
> we obviously have to lose some things.
>
I don't follow you. In original code, we only reap the BIO's on which IO
is complete. How is it controlling peak consumption ?
Now, I give back the BIO as and when IO is complete. So it should be better
for consumption. Isn't it ?
- Badari
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Sep 23 2002 - 22:00:28 EST