Re: [RFC] [PATCH] 2.5.35 patch for making DIO async--performance numbers

[Badari Pulavarty]

> 
> 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