Digging old stuff..

Jason Thorpe <thorpej@nas.nasa.gov> writes:
> I'm told that the reason NT moved graphics from being a "process" (actually,
> something very similar to a Mach server) to the "micro"-kernel was for
> performance..  However, I don't see _any_ performance problems with
> X on my NetBSD systems [..]

I do not know details of X11 or GDI or the mechanism used in NT to
bounce system calls back to user land etc so I can speak with the
total confidence derived from complete ignorance. I think that
graphics calls in NT work very differently from X11. I think a lot of
them are handled with system calls in NT. Therefore moving GDI to
kernel is a performance save in NT. It is a real horror if you look at
it from the point of view of reliability. Imagine running X11 in
supervisor mode.. shudder..

The observable fact is that NT 4 is a lot faster that NT 3.51 in for
example filling out a list box in a dialog with 1000 entries. If you
look at what is happening in NT 3.51 with for example Reskit
QuickSlice (CPU usage meter), you see the application process and
csrss.exe (the Win32 "subsystem" process) eating CPU, a lot of which
is in system (kernel/supervisor) context.

The performance aspect is not the only problem with NT graphics calls.
Apparently a lot of (some? all?) these calls are handeled
synchronously, i.e. in at least NT 3.51 the calling process is blocked
till csrss.exe has done its job. This means that your high priority
process/thread in effect lowers its priority when executing graphics
calls. Or the other way aroud - your low priority screen saver may
starve a higher priority process/thread with time consuming graphics
calls.

Humm.. not very relevant to NetBSD/tech-kern, but apparently the
traffic here isn't now excessive. I think NetBSD can gain from looking
at other OSes - by avoiding mistakes and by adopting good practices.
For example the two stage interrupt processing in NT is a good idea
but the idea was broken by collapsing the second stage processing
(deferred procedure calls) to a single priority level. Obviously there
is a need for priorities at this level too, but it seems that the MI
softints are going to have priorities so this is going to be just
right in NetBSD :)

Actually I think the soft priority levels used by different device
drivers should be even configurable by user. I know just about nothing
about the spl/ipl things in NetBSD so this might be very irrelevant
now, but maybe in future NetBSD which supports hard real time
applications :)