lkml.org 
[lkml]   [1999]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [OFFTOPIC] Re: disk head scheduling

> Sender: owner-linux-kernel@vger.rutgers.edu
> From: Linus Torvalds <torvalds@transmeta.com>
> Date: Sat, 20 Mar 1999 14:05:16 -0800 (PST)
> To: Tim Smith <tzs@tzs.net>
> Cc: linux-kernel@vger.rutgers.edu
> Subject: Re: [OFFTOPIC] Re: disk head scheduling
> -----
> On Sat, 20 Mar 1999, Tim Smith wrote:
> >
> > Linus is almost certainly right that its not worth it--I sure don't want
> > to put up with around 12 hours of probing at install time to get the real
> > geometry...and probably another several hours of probing whenever the disk
> > detects and remaps a bad block.
>
> Note that even if you know exactly what the disk geometry is (and I agree
> that you can certainly find out - it's just a _lot_ more painful than just
> asking the drive what the geometry is), that is only a fairly small part
> of the picture if you actually want to get the perfect disk access
> patterns.
>
> More important than the geometry by far be be the disk cache algorithms on
> the controller. Just about all drives do their own level of caching, and
> the algorithms are not obvious or even the same from manufacturer to
> another (or even from one disk to another).
>
> For example, of the on-disk RAM, some of the area may be used for other
> things than caching altogether (block mapping information etc), and the
> rest may be either one single track buffer (which could or could not
> depend on the actual disk geometry), or multiple "fixed-sized" disk cache
> areas, either used in a LRU or FIFO manner, or in some cases a real sector
> cache.
>
> So when you try to schedule a new request, the best schedule _may_
> actually be completely nonobvious simply because it might be close to an
> old request that still has the track buffer in the on-disk cache.
>
> There was some work done on a "cache-affinity" based request sorting
> algorithm, and the results were interesting (sadly the code was too
> specific to a certain disk and controller type to be generally usable in
> the kernel).
>
> So even if you have a perfect model of the disk itself, if you really want
> to be good you need to have a model of the disk _electronics_ too.
>
> I much prefer the notion of "perfect is the enemy of good", and I prefer
> to make something that is simple and _works_, and has no really obvious
> problems.
>
> Linus
>
>

I think Linus has hit the nail on the head here... The disk systems
(and even individual disks) are getting smarter and smarter, and more
complex. Naive approaches that try to model these systems and out-guess
them are doomed to death by complexity and failure, in IMHO...

There was a paper at OSDI '99 I didn't pay much attention to at the time
(never having been an I/O systems guru) that attempts to help this problem
by various hints getting passed between the disk subsystem and the operating
system, and the people involved were talking to the disk drive manufacturers
to try to get them to implement these hints. I could dig this up out
of the proceedings if people are immediately interested, though I believe
the discussion is mostly moot until such disks and controllers start to
become available.

My impression at the time I was mostly ignoring the paper was that this
approach was much more likely to succeed than the "traditional" approaches
taken by things like the Berkeley FFS layout code, which showed that there
were problems with the approach about the same time that 4.2BSD shipped,
as disk controllers were just starting to get smarter (and Digital was
not very cooperative in describing the disk geometry either, at the time,
with MSCP controllers hiding the geometry of the disks connected to them).
And disks and controllers have only gotten more complex since then...

Was anyone else on this mailing list present and awake enough to remember
the gist of this paper?

Overall, the layout model to maximize performance is getting more and
more complex as the years go by, so lets look for ways the OS and
the disk subsystems can cooperate rather than believe that "the OS is
always right" or the "disk system is always right"...
- Jim Gettys

-
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:50    [W:0.147 / U:0.732 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site