Subject: Re: [linux-audio-dev] Performance and Elegance? (Was: High Cost of IPC)
From: Paul Davis (pbd_AT_Op.Net)
Date: Wed May 16 2001 - 03:32:03 EEST
Just to keep up the civil tone, I want to pass on my thanks to Jay for
his comments.
>My concern is that Linux is an OS under continuing development,
>and I recall that other (non audio development) folks are concerned that
>Linux's performance drops off under heavy load, too.
Jay, please understand that the central concern here is not "load",
but unavoidable costs of context switching. Even on a machine with
zero load besides the audio stuff, Abramo and Steve's work calibrates
the obvious: that there is genuine, if sometimes small, cost to
switching between processes.
I may be wrong,
>but I believe this is a factor that the kernel developers know they
>need to look into.
this is an area of OS performance that has been under study for 20-30
years. I was a systems programmer for the research group at UW CS&E
that had a dozen or so grad students and 4 senior faculty working on
the general issues. there is a very interesting paper at UW CS&E that,
despite being, oh, 10 years old(?) now, is still totally relevant. I
don't recall the exact title, but to paraphrase the general message:
processors have gotten faster, but applications are spending more real
clock time than ever dealing with the kernel in one way or another, so
why is this?
the solutions to the kinds of problems that we're discussing are not
just matters of tuning parts of the kernel. they require a radically
different kind of OS design, something that Linux is not likely to
have at any time in the near to mid-term future.
>The thing is, if we pick a software architecture that trades simplicity,
>beauty, flexibility, etc., for performance, then what happens if
>the kernel changes such that our original analysis no longer applies?
>It will make us all look really stupid in retrospect if we later find
>we've done that.
the performance problems we are discussing relate to the basics of
contemporary computer architecture. unless you want to plan on running
on a Tera, and/or use a 64-bit single-address space OS, no change to
the kernel is going to fundamentally alter the costs of IPC induced by
the cache and TLB.
Given how little has fundamentally changed in OS design over the last
10 years, I am quite content to base a design for what we're talking
about on the ways that more or less every OS you could run right now
operates.
[ X Windows ]
>focusing on having a huge feature set rather than performance, and it took
>about 10 years before it would run on common computers with good performance.
I don't feel that's true. Unless you're trying to say "it wouldn't run
on whatever x86 existed in 1986". Almost nobody using Unix cared about
x86, and so almost no work was put into efficient x86 (i.e. VGA, SVGA)
drivers for X. Once x86 ports of Unix systems started to appear, so
did efficient versions of X for the relevant h/w. I was using X10 on
Sun's in '86-87, and within a year or so of X11 appearing, I was using
a pretty good (not great, but not bad) X11 implementation for
Interactive Unix on the x86.
--p
This archive was generated by hypermail 2b28 : Wed May 16 2001 - 03:45:20 EEST