Con is over-simplifying here -- he is saying the number of
regression-reporters is dwarfed by the number of positive responses.
One regression in particular, though, is rather persistent, and we are
unsure of how to solve it in a way that fits the ideals of RSDL.
There has been one class of problems that have been reported against
RSDL (problems with X or some X+GL-based app in the context of
CPU-intensive programs) that has yet to be "resolved", AFAICS. The
possible solutions being brought up (e.g. auto-nice in the kernel) go
against the fundamental reasons and logic behind RSDL.
The latest (RSDL 0.31) is supposed to help with relatively-niced
latency-sensitive programs (which were reported earlier) and there is
some progress, although I believe maybe one or two people are still
reporting issues here. We are making progress in this circumstance
that Con feels is acceptable. (Again, the remaining potential
solutions being proposed so far go against RSDL's fundamental ideals.
If we actually have to use these solutions, then basically we're just
doing the vanilla scheduler all over again -- defeating the purpose of
RSDL in the first place.)
akpm, IIRC, reported an issue on PPC with an early version of RSDL
(presumably a broken one) when he tried to build the first public
release with -mm; we have yet to hear negative feedback from him (on
the -ck list at least) saying this problem persisted with future
releases.
I think the idea is that Con has seen much greater positive response
(particularly with earlier releases, i.e. a week ago), and a lack of
thorough, viable solutions (particularly ones that either come with a
patch or fit in with the current ideal of RSDL) for the complaints
being brought up that he is feeling frustrated. (Con's neck problem is
preventing him from spending too much time coding solutions himself,
and I feel the discussion that is going on here is starting to become
counterproductive in consideration of that.)
I've also seen no one mention the possibility of slowdowns on RSDL
being a placebo effect type thing. That said, this "regression" on
the "broken code" in X is probably an issue that we do need to at
least watch for. The "average" desktop user, I would assume, is
probably running X. (The question is, whether they would be running
"too many" CPU-intensive programs at the same time. If so, then I
would imagine they're not "average" any more, but I could some
misunderstandings about this.) I think many of us have certain ideals
about the performance of graphical user interfaces (we'd like X to be
super-responsive, all the time, regardless of what processes are
running, with as little impact on the CPU-intensive processes as
possible) although I don't think we're at the level where we can get
there yet. The question is (for the time being) how we're willing to
assign things in this circumstance.
And, as far as I can see, no one appears to have even attempted to
answer Con's question of how much CPU a nice 5 process should get
relative to nice 0, etc., apart from maybe Con himself.
Personally, I think a nice 5 process should get 50% of the CPU time of
a nice 0, but I'm not sure how that would scale to nice 19 or nice
-19.
--
-- Michael Chang
~Just the crazy copy cat~
-
