Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Elevator code (was Re: Darwin disk I/O - better interactive response)

On Tue, 23 Jan 2001, Peter Bierman wrote:

> You guys are drifting waaaaay off into meta-arguments.
>
> Might I suggest that you agree do disagree (or at least misunderstand each other?)
>
> If you have a specific change that you think should be made to darwin, we can discuss that.
>
> We talked about ordering the write que, and it was mentioned that this would be counterproductive, since the device firmware now does this for us.
>
> We can talk about fine tuning the scheduler, but this is something that people spend months on, using as much real world data as possible, and it's still a black art, capable of causing all sorts of priority inversion problems. It's a subject best left lightly discussed unless you have a *specific* change that you want to make, and then you'd better be prepared to defend your changes.
>
> You have the code. If one has a point to prove, then one should prove it.
>
> As for Apple's goals for darwin... they're simple. We want it to be fast. :-)

I thought about this a couple of weeks ago. I wanted to play MOO II under
OS X, but the installer refused to run. Instead of rebooting to install it
I decided to manually copy of the files over. I started by copying the
files, and then started a second copy to grab a bunch of the optional
stuff, so I would not need to keep the CD in (or at least not use it, I
think it needs to be in for the game to run, silly copy protection).

There is a point to this though. When I was copying the first one things
were going pretty fast. When I started the second copy not only did things
slow down massively (way slower then copy the two things sequentially), I
could *hear* a massive change in my DVD-rom as it seeked back and forth
every second or so, which it had not been doing when it had been doing
only one copy.

Now maybe I just have a DVD-rom with stupid firmware, but it seems to me
that this is a prime example of why one might want to have some sort of
elevator code. It could reorder some of the pending writes (and possibly
avoid them) to effectively alter the quanta under which the to copies
switch, and massively increase the throughput.

I am not sure that this applies to harddrives as much, they are much
faster, and are different... But perhaps it should be considered.

Louis

References: 
 >Re: Darwin disk I/O - better interactive response (From: Peter Bierman <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.