Messages in this thread | | | Subject | Re: Time sliced CFQ io scheduler | From | Nick Piggin <> | Date | Wed, 08 Dec 2004 13:33:33 +1100 |
| |
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.
- 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/
| |