Benefits from computing physical IDE disk geometry?

Benefits from computing physical IDE disk geometry?

Post by Chuck Ebber » Tue, 15 Apr 2003 04:40:07



Quote:> You couldn't even tell where such boundaries exist, or what the real
> block size of the underlying media is. Cyliners are all different sizes.

 Not even if you do timing tests?  I know people have done tests that
pinpoint where the xfer rate changes, for example.  I'm sure it
wouldn't be easy, but I bet you could get some useful information.
And at the very least, remapped sectors should be easy to spot...

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Benefits from computing physical IDE disk geometry?

Post by Chuck Ebber » Tue, 15 Apr 2003 05:50:09



> You couldn't even tell where such boundaries exist, or what the real
> block size of the underlying media is. Cyliners are all different sizes.

  Found this by accident while skimming a new book; haven't visited yet
but it may be of interest:

    A technical report describing Skippy and two other disk drive
microbenchmarks (run in seconds or minutes rather than hours or days)
is at

      http://sunsite.berkeley.edu/
             Dienst/UI/2.0/Describe/ncstrl.ucb/CSD-99-1063

(Hennessey & Patterson 3rd ed., Ch.7, exercise 5.)

--
 "Let's fight till six, and then have dinner," said Tweedledum.
  --Lewis Carroll, _Through the Looking Glass_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Benefits from computing physical IDE disk geometry?

Post by Nick Piggi » Tue, 15 Apr 2003 06:00:09




>>The benefit I see is knowing the seek time itself (not geometry), which
>>can be used to tune the IO scheduler. This is something that I'll
>>probably need to do (in kernel) in order to get my IO scheduler in 2.6,
>>as it probably (not tested yet) has bad failure cases on high seek time
>>devices like CDROMs.

>Well, that IS the heart of the matter, really.  Detecting geometry was only
>a means to the end of predicting seek time and rotational latency.

OK yeah. I thought you had more * techniques in mind
like rotational latency optimisation which require actual geometry

Quote:>  If you
>could magically predict the seek time between any two accesses, then you
>could sort your queue optimally.

Well using the assumption that |head sector - target sector| gives
an ordering correstponding to seek time, we do sort the queue optimally.
I personally feel that being trickier than that is too much complexity.

Quote:>What would be able to do that?  A neural
>net?  :)  What would be able to do that without a lot of training time?

I think just some averages, maybe histograms. Not quite sure exactly
how I'll need to do it. I probably want each IO submitting process'
average seek time, and the average seek time when changing from one
process to another. Nothing too fancy.

Quote:

>Personally, I've been e*d about AS, and I would hate to see it not get
>in.

It is getting there. It definitely does some things much better than
deadline, although in other areas it is not so good.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://www.veryComputer.com/
Please read the FAQ at  http://www.veryComputer.com/

 
 
 

Benefits from computing physical IDE disk geometry?

Post by Nick Piggi » Tue, 15 Apr 2003 06:40:10




>>  OTOH you can come up with scenarios like, say, a DBMS doing 16K page
>>aligned IO to raw devices where you might see big gains from making sure
>>those 16K chunks didn't cross a physical cylinder boundary.

>You couldn't even tell where such boundaries exist, or what the real
>block size of the underlying media is. Cyliners are all different sizes.

Yes this is getting very difficult as Alan said. Its also something
that we can't do in kernel - the block io scheduler can only choose
from what it is given. I wouldn't be surprised if big databases did
try using some sorts of disk mapping systems to help optimise
their IO however.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Benefits from computing physical IDE disk geometry?

Post by Mark Hah » Tue, 15 Apr 2003 08:50:11


Quote:> >>The benefit I see is knowing the seek time itself (not geometry), which
> >>can be used to tune the IO scheduler. This is something that I'll

but seek time is some combination of headswitch time, rotational
latency, and actual head motion.  the first three are basically
not accessible in any practical way.  the latter is easy, and the
current approximation (seek time is a linear function of block distance)
is very reasonable.

adjusting the cost function would be interesting: I'm guessing that
handling short seeks (which are quite fast) would be more important
than adjusting for zones.  given that the current queueing code
handles starvation, I wonder if we could actually permit backward
seeks of, say, 0-2 cylinders.

Quote:> Well using the assumption that |head sector - target sector| gives
> an ordering correstponding to seek time, we do sort the queue optimally.
> I personally feel that being trickier than that is too much complexity.

exactly.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Benefits from computing physical IDE disk geometry?

Post by Nick Piggi » Tue, 15 Apr 2003 15:40:04



>>>>The benefit I see is knowing the seek time itself (not geometry), which
>>>>can be used to tune the IO scheduler. This is something that I'll

>but seek time is some combination of headswitch time, rotational
>latency, and actual head motion.  the first three are basically
>not accessible in any practical way.  the latter is easy, and the

Yep which is one reason why I don't think being fancy will pay
off (the other reason being that even if you did know the parameters
I don't think they would help a lot).

I just want to know the average seek time.

Quote:

>current approximation (seek time is a linear function of block distance)
>is very reasonable.

Well, strictly, not linear. But yes it does provide a good ordering.
That is besides the point though: I can decide if one request will
have a shorter seek time than another just fine. I would still like
to know the aproximate seek _time_ for higher level tuning stuff
eg. will anticipation be worth it, and how soon should requests
expire.

Quote:

>adjusting the cost function would be interesting: I'm guessing that
>handling short seeks (which are quite fast) would be more important
>than adjusting for zones.  given that the current queueing code
>handles starvation, I wonder if we could actually permit backward
>seeks of, say, 0-2 cylinders.

There is (in AS) no cost function further than comparing distance
from the head. Closest forward seek wins.

If by the queueing code you mean the actual IO schedulers? Then
yes, they do handle starvation, however they (AS, deadline)
handle _fairness_ by not seeking backward. Well actually
AS does allow a process to seek upto IIRC 256MB backward
which is a couple of ext2 blockgroups while maintaining quite
good fairness.

Quote:

>>Well using the assumption that |head sector - target sector| gives
>>an ordering correstponding to seek time, we do sort the queue optimally.
>>I personally feel that being trickier than that is too much complexity.

>exactly.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

Benefits from computing physical IDE disk geometry?

Post by Wes Felte » Tue, 15 Apr 2003 20:50:16



> So, what if one were to write a program which would perform a bunch of
> seek-time tests to estimate an IDE disk's physical geometry?  It could then
> make that information available to the kernel to use to reorder accesses
> more optimally.

Greg Ganger et al. have done some recent work in this area:

http://www.pdl.cmu.edu/PDL-FTP/stray/freeblocks_abs.html
http://www.pdl.cmu.edu/PDL-FTP/stray/traxtent_abs.html

--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Benefits from computing physical IDE disk geometry?

Post by Chuck Ebber » Tue, 15 Apr 2003 23:40:12



>>but seek time is some combination of headswitch time, rotational
>>latency, and actual head motion.  the first three are basically
>>not accessible in any practical way.  the latter is easy, and the

> Yep which is one reason why I don't think being fancy will pay
> off (the other reason being that even if you did know the parameters
> I don't think they would help a lot).

 The graphs in the "skippy" disk benchmark paper are
interesting -- some disks show bizarre peaks and dips in their
times across increasing sector distances. (The lesson here might
be to test your disks and avoid the bad actors rather than try
to compensate for their behavior, though.)

Quote:> There is (in AS) no cost function further than comparing distance
> from the head. Closest forward seek wins.

 The RAID1 code has its own scheduler that does similar things.  Why
aren't they being integrated? (See raid1.c:read_balance())

--
 Chuck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Benefits from computing physical IDE disk geometry?

Post by Nick Piggi » Wed, 16 Apr 2003 02:10:07




>>There is (in AS) no cost function further than comparing distance
>>from the head. Closest forward seek wins.

> The RAID1 code has its own scheduler that does similar things.  Why
>aren't they being integrated? (See raid1.c:read_balance())

If RAID1 can use the generic elevator then it should. I
guess it can't though.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/