Re: Time sliced CFQ io scheduler

[Andrea Arcangeli]

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

In the desktop distro you'll notice the /proc/cmdline has elevator="as"
because for desktop distros more people is going to use them for
desktop as expected.

But for enterprise distros this isn't the case, and cfq (or deadline)
must be the default, sure not "as". So claiming that selecting cfq by
default (I said in the enterprise distro) is deoptimising users, is
a wrong statement and the opposite of reality.

And personally I use cfq even on the desktop (since I'm not a normal
desktop user and I've apps writing too).

> AS needs another iteration of development to fix these things.  Right now
> it's probably the case that we need CFQ or deadline for servers and AS for
> desktops.   That's awkward.

Exactly.

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.

Desktop is already forced to "as" by /proc/cmdline, so it's not affected
on how we change the default of the enterprise distro AFIK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/