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

Re: Darwin disk I/O - better interactive response

Originally I responded to Chuck privately, but apparently he feels the
issues raised are worthy of discussing with the entire list. Far be it from
me to disagree with so esteemed a member of the community...

> On Mon, 22 Jan 2001 19:38:09 -0800, John Metzger wrote:
> [ ... ]
>>> Dave, whatever you might contribute to Darwin will be more valuable if
>>> you stop assuming that everyone is going to be using Mac hardware the way
>>> you currently do.
>>
>> Regardless of the hardware the issue is a personal computer not a server
>> farm. Some of us (well at least me) are not interested in servers. We're
>> interested in personal machines, a good example being the Mac.
>
> You've entirely missed my point. An analogy by parody:
>
> "Some of us are not interested in personal computers. I have no interest in
> a machine unless it's locked in a rack at a colo facility and I have to ssh
> into it."
>
> Even if I held that position, it would be wrong of me to assume that
> everyone else uses computers the same way I do.

Good. Then you might agree that some of us don't want to use Darwin as
merely a server or merely a BSD variant, but would like to see it DEVELOP
into a more Mac like PERSONAL computer OS with concepts and capabilities
similar to Mac OS X (or even something beyond OS X).

> If I recognize that other
> people want to use a Mac

or Darwin...

> in many different ways, than whatever changes or
> suggestions I might make would be more useful to a broad range of people.

ditto.

First this is about Darwin, not Macs. My interest is how to use Darwin to
build something that is Mac like, i.e. a personal computer, a big Palm
Pilot. Thus discussing how to get Mac (or Mac OS or Mac OS X) like
functionality with Darwin is what I'm most interested in. If others are
interested in Darwin as merely a GUI-less, BSD Unix variant fine.

Yet comments I make about what I think needs to be changed or added to
Darwin routinely get shot down as "That's not what Darwin is about. It's
Unix damnit and there is no Finder, yada, yada, yada... "

So perhaps if you listened to your own comments ... and understood the
broader uses of Darwin, instead of the narrow ones you like to focus on...

> On Sat, 20 Jan 2001 11:24:37 -0800, Dave Yost wrote:
> [ ... ]
>> I am seeking a disk driver expert who knows about the following:
>>
>> If they wanted to, could Darwin disk drivers sort requests based on the
>> requesting process's priority, or would there have to be a change to the
>> driver protocol?
>
> The simple answer is no. Device drivers are responsible for servicing
> low-level I/O requests; they have no knowledge of the upper levels of the
> system (by design), nor should they.

This is one of the things that is wrong with the "traditional" Unix way of
doing business. Of course the lower layer should be aware of the needs of
the higher layers, that's what the lower layers are for -- to service the
higher layers. You just see no use for a Finder or optimizing a system to
support interactive use, rather than batch file serving use.

I sure hope Apple doesn't take this attitude with OS X. Everything in a Mac
should be there for one reason and one reason only. To support the HI. Get
it? It's a frigging personal computer, not a damn time sharing file server.
It should be designed from the point of view of what the user wants to
accomplish and supporting that to the best degree possible, not some silly
notion of "clean" system design from a Unix timesharing system point of
view.

...
>> Is designing and building a replacement Finder/Workspace (enhancing Gnome,
>> KDE or something) for Darwin a topic for this list?
>
> It would be. Regrettably, your position seems to have more to do with
> ideology than with writing code.

Ideology (or I'd call it system design) first, code later.

Getting the "design" right, from top to bottom is important. Do the design,
then write the code. Not the other way around. Design the house, then build.

>>>> I further claim that the above goal requires that disk I/O scheduling be
>>>> prioritized and preemptive, just as processor scheduling is, even more
>>>> importantly because of the vastly slower performance of disk vs. cpu.
>>>
>>> There isn't a simple correlation between system responsiveness and your
>>> notion of prioritizing disk I/O.
>>
>> This issue is exactly why there maybe some need to modify the Darwin kernel
>> to better support the higher level GUI/HI...
>
> Not likely. The design of Darwin is optimized towards maximizing overall
> throughput rather than prioritizing system resources towards the foreground
> task at the expense of other tasks.
>
> The latter design is pretty much how the classic MacOS worked, as well as
> Windows, and seems to be what you and Dave are advocating. Apple is
> switching AWAY from that design for reasons that they must think are valid.

I hope not. Yes, I expect the foreground task on a system like OS X or more
importantly my command directives (via mouse clicks, etc.) to be top
priority, not something the system thinks is of higher or even equal
priority. I fully expect my input to redirect the system's attention as
rapidly as possible. If getting a better HI means re-ordering the disk
queue, then the system ought to support it, top to bottom.

This is what I mean (excuse the ideology here) by the system being designed
(or changed) to support a given task optimally. If you want high performance
servers then servicing the HI as a top priority is the wrong thing to do. IF
you want a different kind of system than a server, a personal computer, then
just perhaps an OS oriented toward being a server isn't the best choice.

Can Darwin serve both kinds of uses optimally with no changes from the Unix
core or the Unix way of abstracting the low level so they know nothing of
high levels needs or functions?

>> For instance the Finder/Workspace replacement (Gnome or KDE) might need
>> code which can re-order the disk queue to better respond to user input and
>> provide better user feedback. That might need changes that trickle all the
>> way down into the kernel and io system.
>
> No. One reason why Apple switched to Darwin is because the Unix design for
> maximizing throughput is more scalable and does better for more complicated
> systems which run many processes at once,

Why should we care about that in a system that is designed for personal use?
I.e. a Mac as opposed to a Mac OS X Server. I'm not interested in maximizing
throughput. I'm interested in maximizing the response to the user. To the
extent that maximizing throughput helps that end fine. BUT, if my goal is to
use Darwin to get a Mac like system then maximizing the performance of the
user interface is more important than maximizing overall system throughput.

> and where background tasks are
> every bit as important to the end-user "feel" as the foreground task.

So some number crunching task and some disk bound copy should have equal
priority with displaying a new window? Those background tasks can and should
be pre-empted, if they are truly background tasks. Those tasks supporting
the HI even though they are running as background tasks should have higher
priority than a background tasks that is running a routine file back up to a
server or one that is calculating PI to the nth digit.

Not all background tasks are of equal importance to the user experience.

> Specificly, software like Gnome and KDE are going to run far better under
> Darwin than they would under the classic MacOS.

So? What's that got to do with the price of beans in China? The issue is can
they run even better, IF changes are made to the lower levels of the kernel
to better support the higher level software's needs?

> It's the same reason why
> WebObjects under Windows NT and Win2K performs MUCH better when you DISABLE
> the "optimize performance for foreground applications" preference.

But of course I don't want WebObjects to work better on my PERSONAL
computer. (I don't want WebObjects on it all but that's a different
issue...). I specifically want better performance for the foreground tasks
and those background tasks that are directly supporting my foreground task.

> Darwin's design does have it's weaknesses, of course. Adding realtime
> support would do much to address them and to make the end-user experience of
> using software like QuickTime, multimedia streaming, and Aqua better.

Yeah, well this is Darwin development, not Mac OS X development. So comments
about QuickTime, Aqua et. al. don't apply......


except as how to get adequate replacements for those things, for those of us
that would like Darwin as something other than a GUI-less, multi-media-less
dumb ass Unix time sharing, file serving system... (Not that dumb ass Unix
time sharing, file serving systems aren't useful to many people..... I'd
just like Darwin to be used a little more broadly...)

> Breaking the abstraction layers between device drivers, the VFS/filesystem
> layer, and userland processes requesting I/O is likely to do more harm than
> good, particularly if the change was done by people who don't understand the
> new architecture and the real tradeoffs involved.

Well maintaining Unix ideological purity should not take precedent over
getting a better user experience (IMO) on either Mac OS X or whatever
substitutes for the missing higher layers in Darwin...

A system which is supposed to be USER centric ought to be, instead of system
centric or server centric, and may just need some additional mechanisms in
the kernel to help out when needed.



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.