Not on a tuned system. As I've said before: not using broken drivers
is a major win. Doing that is easy. Next come other effects, and
scheduling latency is one addition to latency in the chain that
produces the "worst case" values.
> 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.
I've consistently said that there are other contributions to
latency. I am focussing on one in particular. Reducing that particular
one will reduce overall latency. Others are tackling other
contributors to latency, and I have some simple strategies for
reducing the major contributor (broken drivers) to latency.
So, a simple solution to solve the first-order problem. Now there are
a bunch of second-order problems which are being addressed.
> 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?
Go back to what I've said before. I've covered this.
> : 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.
No, it doesn't have to be the most important factor for it to be
worthwile to fix.
> 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.
No, again not true. As I've said before, the change I propose will in
fact *simplify* the scheduler code path.
> 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.
No, Larry. You just don't get it, do you? It's rude to be abusive. It
is not rude to have a different point of view.
It is utterly absurd to say I'm being 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'm not ignoring people. I just don't agree with your point of view. I
have numbers which convince me there *is* a problem and I think I have
a costless solution. I'm entitled to my view.
As for my knowledge and experience, you have no idea how much I have:
I haven't advertised what I know and I don't brag about it. An idea
should stand on it's merits, not on the reputation of it's proponents.
I'm not interested in puffing up my chest, nor am I interested in
comparing medals.
> : 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.
Not true. I've explained why many times before.
> 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.
I've already explained why there are problems for us to use
RT-Linux. This is why I'd rather squeeze more performance out of
standard Linux.
Regards,
Richard....
-
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/