Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!heksterb
From: heksterb@Apple.COM (Ben Hekster)
Newsgroups: comp.sys.mac.system
Subject: Re: Preemptive scheduling
Summary: How well do disk drives and schedulers mix?
Message-ID: <48184@apple.Apple.COM>
Date: 16 Jan 91 23:07:19 GMT
References: <1991Jan16.035715.4711@maverick.ksu.ksu.edu> <48172@apple.Apple.COM> <1991Jan16.214809.25818@maverick.ksu.ksu.edu>
Organization: Apple Computer Inc., Cupertino, CA
Lines: 109

jxf@orion.cis.ksu.edu (Jerry Frain) responds to my latest posting:

> Before you read my article, let me just say that I _do_ like the Macintosh.
> I own one, and I like it.

Hey, I like workstations (although I don't own one).

> The important thing to keep in mind here is that there is _always_ room
> for improvement.  If everyone was so against improvement, we (as a Mac
> community) would still be using Finder 1.0 on the original Mac.

No argument here.  I *do* have an argument as to where this improvement is
significant or worthwhile.

>>[ explanation of poor performance on HP 9000 workstation ]
>
> Sounds like your system needs to be reconfigured.  Anything that has
> difficulty doing what you described ought to be fixed or junked.

It was already suggested to me that it could probably use some more memory
to cut down on swapping.  However, even at times when I was the only user
response was never (as you say it is in your case) "instantaneous".

> How about "mouse response on the Mac goes away during volume recognition."

Yes, but I mean, how does that relate to (or improve under) different types
of multitasking?

> I don't have a mandelbrot background.  I have a mouse.  Perhaps I have
> inserted the floppy so that I may copy a file to the floppy disk.  Haven't
> you ever tried to open the folder that the file is in while the Mac is
> trying to figure out what the name of your disk is?
>
> The jerkiness of the mouse caused by volume recognition is just damn
> _unnecessary_, and irritating.

I'm not familiar with details of the Disk Driver, but I always assumed that
since the CPU (on machines other than the IIfx) is doing the transfer, it
would not be possible to enable mouse interrupts as well without losing some
of the sector.  Since disk accesses are so time-critical the CPU cannot afford
to lose *any* time.  Note that this would mean having to wait for the media to
complete an entire rotation in order to attempt the read again.  I also
suspect it would have a significant impact on the ability to quickly read
(or cache?) consecutive sectors.  I obviously haven't tried enabling mouse
interrupts, but I would suspect it wouldn't be too difficult to slow disk
accesses down to a crawl by moving the mouse continuously.

> Gee, isn't that entirely against the philosophy of the Mac's cooperative
> scheduler?  Isn't the interactive user supposed to get good response
> time *no matter what*?

No, no, no, that is *certainly* not what a cooperative, or any sort of
scheduler presumes or can do.  The response time is fundamentally limited to
the hardware.  No scheduler can make the hardware itself run faster.  If,
assuming that it is indeed the case that the CPU is not significantly faster
than the drive, any sort of scheduling will make disk access significantly
slower.  Having the OS preempt the Disk Driver while it is in the process of
mounting will not make it any faster.

> Your argument above is what most people use to
> argue *against* preemptive scheduling, the idea that the interactive
> user might not get prompt responses!

The argument I am making for non-preemptive scheduling is that it is up to
the programmer to decide at what points it is useful or desirable to give up
time to other tasks.  Presumably the implementers of the Disk Driver thought
that getting the disk access over with as quickly as possible was more
useful than making the mouse move.  A preemptive scheduler makes this
decision *for* you, how well, depending on the scheduler used.

> You cannot tell me that during the time period that volume mounting is
> taking place, that the CPU is _really_ busy.  Probably less than 1/1000
> of the delay experienced is actually due to the fact that the CPU is
> too busy to move your mouse.

But the mouse is also not completely disabled during the *entire* mount.
Probably, I would suspect, only at times when actual disk accesses are
taking place.  I agree that the time required to move the mouse may not
be incredibly much (although, with multiple screens with different depths
it may not be that easy, either), but then the timing constraints of disk
drives are somewhat stringent.

> I think that *both* mouse responsiveness and volume mounting should be
> provided at the same time.  It can be done.  Why do you not desire this?

But I do.  That's why I like my IIfx so much.  It can be done, but it requires
hardware support.  Because the IIfx's IOPs relieve the CPU from doing the disk
accessing it is free to handle mouse movement stuff.

> What?  Are you kidding?  The answer is "none."  The scheduler is part of
> the operating system, which is not represented as a process.

I don't mean the scheduler per se, I mean system processes like daemons which
are not directly related to user programs.  Perhaps my question was badly
phrased, it was really just as a matter of interest.

> The responsiveness of my mouse pointer (or anything else for that matter)
> is instantaneous.  Just like my Mac.

> Have a nice day.

You too!

_______________________________________________________________________________
Ben Hekster                           | "I've had my fun
Student intern                        |  but now it's time
AppleLink:   heksterb                 |  to serve your conscience
Internet:    heksterb@apple.com       |  overseas"
BITNET:      heksterb@henut5          | --Orange Crush, R.E.M. (Green)