lkml.org 
[lkml]   [1998]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: elevator algorithm bug in ll_rw_blk.c
Date
From


> Thanks to several who gave me an education about true disk geometry vs
> reported. I do have a follow-on question. The hdparm command for
> example can determine the drive model. Given that, and data sheets,
> shouldn't a hd driver be able to choose from a database of tuning
> parameters to optimize drive access? The fallback could always be the
> simpler, straight-forward approach taken now. This would require either
Who should make that base and keep it updated?
With the tens of thousands of disks available and new models coming in -
the fallback would be used a lot.
> manufacturer's data put into the table, or probably even better, timing
> based on probing of the drive model. Do drives vary much any more
> between copies of the same model, so would an inidividual drive need to
> be optimized, or just a model?
A model satisfies some spec. Nothing stops the manufacturers from
continuing a popular "model" with a different number of platters in order
to save money when technology changes.
Bugfixes to the on-drive cache algorithm could affect timing a lot too.
So I thing you'll have to prober individual drives. Even upgrading your
cpu can affect timing, as a faster cpu have time for more request sorting
during a seek.
>
> Would this be worth the effort? Would we get, say double the read speed
> in general-purpose access, or perhaps in specialized efforts, such as
> large database access?
You would see improvement yes - but probably nothing impressive.
Perhaps 2%-5%, and this is why it isn't really worth it.
Seeking from end to the disk to the beginning is slower than
a shorter seek, but not by much. Moving n tracks idoes not take
n times the time for moving one track, the heads typically move
with constant acceleration/deceleration. And this long seek doesn't
happen often with the current algorithm either.
In short, there isn't much to save.

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/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.082 / U:0.464 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site