WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] blkfront problem in pvops kernel when barriers enabled

On Thu, Sep 08, 2011 at 09:06:09AM +0100, Jan Beulich wrote:
> >>> On 07.09.11 at 19:41, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> 
> >>> wrote:
> >> >> <scratches head>
> >> >> 
> >> >> I can only think of 2.6.38-3 XenOLinux doing it - and it is a bug
> >> >> to do it. It really ought to _not_ advertise 'feature-barrier' and
> >> >> instead advertise 'feature-flush-cache'.
> >> > 
> >> > Indeed, I see that I added feature-flush-cache support to the frontend
> >> > back then, but neglected to do so for the backend. Partly perhaps
> >> > because I'm not much of a (block, network, ...) driver person...
> >> > 
> >> > However, what I'm not understanding with dropping feature-barrier
> >> > support from the backend - how do you deal with old frontends
> >> > wanting to use barriers? I'm currently converting them into
> > 
> > Just not supporting them. I know it is incredibly bad to do so - but
> > I have not had a chance to write the code to emulate the 'feature-barrier'
> > correctly.
> > 
> >> > WRITE_FLUSH_FUA operations in the backend as a (hopefully) best
> >> > effort approach.
> > 
> > I am not sure. I need to run blktrace|blkparse to make sure it does the
> > right think as compared to a WRITE_BARRIER. Lets ask Christopher Hellwig - 
> > he
> > knows a lot of this.
> > 
> >> 
> >> Also I notice you're using WRITE_ODIRECT - what's the background
> >> of that?
> > 
> > Ah, 
> > http://git.drbd.org/linux-2.6-drbd.git/?p=linux-2.6-drbd.git;a=commit;h=013c3
> >  
> > ca184851078b9c04744efd4d47e52c6ecf8
> 
> Hmm, that seems more like a band-aid than a real solution. What if with
> another scheduler (or after some changes to CFQ) REQ_SYNC actually
> hurts (as - without any data - I would have expected)? Can't/shouldn't
> the use of REQ_SYNC be made at least dependent on the scheduler in
> use on the queue?

This is what the header fine says about async vs sync:

 *      All IO is handled async in Linux. This is fine for background
 *      writes, but for reads or writes that someone waits for completion
 *      on, we want to notify the block layer and IO scheduler so that they
 *      know about it. That allows them to make better scheduling
 *      decisions. So when the below references 'sync' and 'async', it
 *      is referencing this priority hint.


To make sure I was not shooting myself in the foot, I did the change and
also made sure the other schedules worked without any regressions in speeds.

But keep in mind that this 'WRITE_ODIRECT' behavior is also used
by AIO, and by any userspace application that stick O_DIRECT on the
open call. So if another another scheduler breaks this behavior we are
not the only one affected.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel