Re: Time sliced CFQ io scheduler

[Nick Piggin <nickpiggin@yahoo.com.au>]

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

I think this would be a decent "it works" solution that would make
AS acceptable as a default.