Here is the difficulty with this discussion:
No documented problem
No reason to believe that the "solution" solves the unspecified "problem"
No clear understanding of the effects of this change on the system
Why, this could be a discusion among AIX developers!
Richard points out a strange result shown by his benchmark. He _guesses_ that
this result implies that (A) there is a performance problem for real
applications and (B) this problem may be solved by a second queue.
But what is the evidence for either? Note that a queue of length 10 is
trivial, a queue of length 100 is most likely trivial on a fast processor.
How about a benchmark with an instrumented kernel showing time spent searching
the queue before we optimize time searching the queue? That is, you should
be able to show that for Application X, wall clock time of T involves T_s
time searching the queue where T_s is a substantial fraction of T.
As it is, we have no solid evidence that there is anything wrong with the
scheduler. In fact, we have DaveM's experience (not
to mention Cort's experience with PPC Linux) to show that hammering out a
few microseconds on schedule time seems to have NO effect on system
performance.
It follows that those who really want to contribute to
Linux performance might consult Alan's list of 2.2 showstoppers or
find some other actual problem. I have a couple of scheduler related problems
for RTLinux that I would love someone to solve. For example, it should be
easy to write a SMP scheduler that would evict all non-rt tasks from a
particular processor after at most N timer interrupts where N is the number
of Linux processes assigned to that CPU. Or maybe someone could rewrite
our RT-fifo module for better performance. Or how about a solid big
physarea? ..
---------------------------------
Victor Yodaiken
Department of Computer Science
New Mexico Institute of Mining and Technology
Socorro NM 87801
Homepage http://www.cs.nmt.edu/~yodaiken
PowerPC Linux page http://linuxppc.cs.nmt.edu
Real-Time Page http://rtlinux.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/