Re: Time sliced CFQ io scheduler

[Jens Axboe <axboe@suse.de>]

On Wed, Dec 08 2004, Nick Piggin wrote:
> On Tue, 2004-12-07 at 18:25 -0800, Andrew Morton wrote:
> > Andrea Arcangeli <andrea@suse.de> wrote:
> > >
> > > On Tue, Dec 07, 2004 at 06:00:33PM -0800, Andrew Morton wrote:
> > > > untuned SCSI benchmark results without realising that.  If a distro is
> > > > always selecting CFQ then they've probably gone and deoptimised all their
> > > > IDE users.  
> > > 
> > > The enterprise distro definitely shouldn't use "as" by default: database
> > > apps _must_ not use AS, they've to use either CFQ or deadline. CFQ is
> > > definitely the best for enterprise distros. This is a tangible result,
> > > SCSI/IDE doesn't matter at all (and keep in mind they use O_DIRECT a
> > > lot, so such 64kib Jens found would be a showstopper for a enterprise
> > > release, slelecting something different than "as" is a _must_ for
> > > enterprise distro).
> > 
> > That's a missing hint in the direct-io code.  This fixes it up:
> > 
> > --- 25/fs/direct-io.c~a	2004-12-07 18:12:25.491602512 -0800
> > +++ 25-akpm/fs/direct-io.c	2004-12-07 18:13:13.661279608 -0800
> > @@ -1161,6 +1161,8 @@ __blockdev_direct_IO(int rw, struct kioc
> >  	struct dio *dio;
> >  	int reader_with_isem = (rw == READ && dio_lock_type == DIO_OWN_LOCKING);
> >  
> > +	current->flags |= PF_SYNCWRITE;
> > +
> >  	if (bdev)
> >  		bdev_blkbits = blksize_bits(bdev_hardsect_size(bdev));
> >  
> > @@ -1244,6 +1246,7 @@ __blockdev_direct_IO(int rw, struct kioc
> >  out:
> >  	if (reader_with_isem)
> >  		up(&inode->i_sem);
> > +	current->flags &= ~PF_SYNCWRITE;
> >  	return retval;
> >  }
> >  EXPORT_SYMBOL(__blockdev_direct_IO);
> > _
> > 
> > > ...
> > > 
> > > If you believe AS is going to perform better than CFQ on the database
> > > enterprise usage, we just need to prove it in practice after the round
> > > of fixes, then changing the default back to "as" it'll be an additional
> > > one liner on top of the blocker direct-io bug.
> > 
> > I don't think AS will ever meet the performance of CFQ or deadline for the
> > seeky database loads, unfortunately.  We busted a gut over that and were
> > never able to get better than 90% or so.
> > 
> 
> I think we could detect when a disk asks for more than, say, 4
> concurrent requests, and in that case turn off read anticipation
> and all the anti-starvation for TCQ by default (with the option
> to force it back on).

CFQ only allows a certain depth a the hardware level, you can control
that. I don't think you should drop the AS behaviour in that case, you
should look at when the last request comes in and what type it is.

With time sliced cfq I'm seeing some silly SCSI disk behaviour as well,
it gets harder to get good read bandwidth as the disk is trying pretty
hard to starve me. Maybe killing write back caching would help, I'll
have to try.

-- 
Jens Axboe