You've conveniently ignored the point that the latency that you are so
concerned about is quite unlikely to be the largest problem. In fact,
it's orders of magnitude smaller that other problems which can occur
and cause your system to fail.
: B: The evidence for a second run queue solving the problem is very
: strong. The numbers I've posted show beyond any doubt that an
: increased run queue length has a measurable effect on context switch
: latency.
So what? Yes, you have showed numbers (which still vary more than the
effect you are measuring, rendering the results meaningless, but let's
leave that aside and postulate that you had perfect numbers with no
variance) that show your benchmark slowing down as you do more work.
Again, so what?
What you haven't shown is anything real about your application. You just
think that this will help but you don't know that. You don't know what
other things could occur to cause your RT process to not respond in time.
Victor pointed out a list of much larger problems and I'm sure the list
was incomplete.
Furthermore, your suggested "fix" is completely specific to your
application with short RT run queues. What happens if you have 10
RT processes? Won't they have exactly the same "problem" that you
are currently "fixing" by moving your processes off the run queue
onto another queue? If that's the case, how can you possibly call
it a RT queue - it only helps you. Shouldn't it really be called the
Short_RT_Process_Queue_For_Mr_Goochs_Possible_Problem?
: A queue length of 3 (extra) is already significant on a
: Pentium 100: the thread switch time is doubled.
So what? Unless you can /show/ that this is actually the most important
factor to your perceived performance problem, you should not be mucking
about with the scheduler.
Because you /think/ that context switching is going to be a problem,
you want the kernel redesigned to specifically match your perceived
(not even proven) problem. In a way that helps only you but does nothing
for applications that don't happen to match your design.
I don't know about the rest of the list, but if you want to start whining
about rude people, I'm starting to think it's pretty darn rude of you
to be suggesting poorly thought out solutions to unlikely and unproven
problems for one poorly designed application. Especially when that
solution includes wacking a scheduler used by millions of people world
wide that will derive no benefit from and may be hurt by your changes.
Now that's rude. That's damn rude.
: I'm not talking about overall system performance. I'm talking about
: the effect of increased latency on latency-sensitive RT
: applications. This is a different world.
Jeez, and you were talking to the guy that worked on RT Linux. Yeah,
he wouldn't know anything at all about RT issues. Did you ever stop to
consider how rude it is of you to ignore people that are (a) trying to
help you, and (b) have far more demonstrated knowledge and experience
in the area than you?
: I would rather spend my efforts improving standard Linux than
: RT-Linux. No offence intended.
First of all, your suggested changes are hardly an improvement. Second of
all, you'd do well to go look at RT Linux. In many ways, it sort of is
the Short_RT_Q_for_MR_Gooch, and as such is a far more appropriate place
for you to do your hacks.
-
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/