>
> what is the slowest part of linux
> i would be most surprised if it wasn't disk accesses - just physically getting the
> blocks on and off the disk
>
> anything which speeded that out by a pico second is going to pay dividends all
> around. on this list people talk about shaving a nano seconds off secheduling and
> what have you. getting the data on to and off the disk is measured in milliseconds.
Waiting more for the disk doesn't slow linux, for linux scedule
other processes when one is waiting. Spending too much time
optimizing requests would speed up an io-bound machine but slow
down a compute-bound one. Add enough RAM and your machine
becomes compute bound as most disk activity hits the cache.
Keeping a huge disk geometry table in memory will give us less memory
to play with. That will result in a few more cache misses and
kill your performance gains. Getting data off the disk is one
of the slowest operations - so having to get more of it is a major
problem. Getting the same amount in a slightly better order
is a smaller improvement. The transfer time is the same.
Helge Hafting
-
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/