Messages in this thread | | | Date | Wed, 18 Nov 1998 14:06:24 +0000 | From | Mark Lord <> | Subject | Re: elevator algorithm considered irrelevant |
| |
> : 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/
| |