Re: elevator algorithm considered irrelevant

Mark Lord (mlord@pobox.com)
Wed, 18 Nov 1998 14:06:24 +0000


> : I once implemented "closest seek" and "2way-elevators" for
> : the Linux IDE driver, and saw marked response improvements
> : under heavy load.
>
> Could you quantify that? Do you remember what was the load generator
> and what was the difference in response time and what was the difference
> in throughput? I'm not trying to argue, I'm just curious as to the
> ballpark results. I can imagine that this is all in some dusty corner
> of your mind but if you can take a swag at the numbers I'd be interested.

I remember measuring stuff at the time, but have long lost
the results of it. My likely-biased memory says that kernel
builds went a good 20% faster, and responsiveness under heavy
swapping/paging went up "quite noticeably" -- a term that usually
means at least a factor of two for us humans to notice it.

Somebody else asked about swapping as well, and I now remember that
it was *because* of swapping that I tried this stuff.

It was frustrating to watch my fast drives spend all of their time
seeking back and forth, a page at a time, between the fs and the
swap partition. Implementing "minimal head movement" cured that
symptom, allowing multiple reads/writes to swap to happen together,
dramatically speeding up response under negative-memory conditions.

But as I posted earlier, much has changed (in hardware and in kernel)
in the past 4-5 years, and perhaps different results might be seen
today.

Heck, for that matter, my drives now run with write-caching enabled,
and that alone makes a noticeable difference under load.

The next biggest thing I *currently* do for interactive response
is use a two-drive RAID0 for my (all-in-one) root filesystem.
With a 64KB chunksize, this effectively scatters I/O across both
drives rather evenly (except for metadata, which always seems to
end up on the first drive for some reason..), allowing good response
even while doing full-filesystem-copies and such.

Cheers.

-- 
mlord@pobox.com

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/