On Monday 15 October 2007 11:38:33 pm Eric W. Biederman wrote:
Mind if I throw in some vague and questionable numbers? :)
I vaguely recall that my old 486 laptop with 16 megabyes of ram (circa 1998)
used to be able to do 3 point something megabytes per second to/from disk,
according to hdparm -t. (That was with DMA enabled.)
This means that my old laptop, using sequential writes and not being bogged
down by excessive seeking, could write its entire memory contents to disk and
read it back in again in about 10 seconds total (5 write, 5 read).
My current laptop has 2 gigabytes of ram, and hdparm -t /dev/sda says:
/dev/sda:
Timing buffered disk reads: 116 MB in 3.01 seconds = 38.54 MB/sec
So that's a little over a factor of 10 speed improvement. (Although I note
that I got 30 megabytes/second off of an ATA/100 adapter in 2002, so it's
barely any faster than it was 5 years ago.)
This means I can expect my current laptop to write out its memory in 50
seconds (2000/40), and another 50 seconds to read it back in.
So 10 seconds to cycle through memory 10 years ago, vs a little under 2
minutes today, on systems at roughly the same price point. And that's
limited by what the hardware is doing, assuming a _perfect_ linear read/write
pattern with no seeks.
Oh, and my old 486 had its RAM maxed out. This one can hold twice as much.
And heavy seeking sucks more than it used to relative to sequential reads by
something like a proportional amount (hence the rise of I/O elevators as a
mitigation strategy), although I haven't got numbers for that handy.
The problem is the gap is getting bigger. The 486-75 laptop mentioned above
had a 25 mhz 32 bit front side bus. A quick google suggests my core 2 duo
has a 667 mhz FSB and I'm guessing a 128 bit data path (two 64-bit channels).
I could boot up memtest86 and get actual benchmarks, but total handwaving for
a moment, 25*32=800 and 667*128=85376, and the second divided by the first is
over 100 times as big. That concurs with the 16mhz->1733 mhz processor speed
increase.
Factor of 10 disk speed increase, factor of 100 memory speed increase. Disks
speeds aren't keeping up with processor and memory increases. Disk _sizes_
are, but speeds aren't.
Do the numbers above help? It'll only get worse, unless some random new
technology (maybe http://en.wikipedia.org/wiki/MRAM or something) swoops in
to change everything, again.
Hence "the seek sucking even more now" part. :(
I'm sure somebody will eventually write an OLS paper or something on the
advisability of making swapping decisions with 4k granularity when disks
really want bigger I/O transactions. Maybe they already have, somewhere
between:
http://kernel.org/doc/ols/2007/ols2007v1-pages-53-64.pdf
and
http://kernel.org/doc/ols/2007/ols2007v1-pages-277-284.pdf
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
-
