Re: RT patch acceptance (scheduler)

[hui]

On Wed, May 25, 2005 at 03:05:58PM +1000, Nick Piggin wrote:
> What is more likely is that you are seeing some starvation from simply
> too much CPU usage by interrupts (note this has nothing to do with latency).
> *This* is the reason ksoftirqd exists.
> 
> ie. you are seeing a throughput issue rather than a latency issue.

That's presumptuous. It's more likely that it's flakey hardware
or a missed interrupt that would cause something like that. I've
seen that happen.

> ksoftirq doesn't alleviate any kind of latencies anywhere AFAIKS.

Ksoftirq is used to support the concurrency model in the RT patch
so that irq-threads and {spin,read,write}_irq_{un,}lock can be
correct yet preemptible.

> softirqs won't normally run in another thread though, right?
 
> Yeah I don't think it is anything close to the same concept of
> softirqs though. But yeah, "just" running top half in threads
> sounds like one of the issues that will come up for discussion ;)

This is not an issue for the regular kernel since they can run
along side with the IRQ at interrupt time. It's only compile time
relevant to the RT. 

And please don't take a chunk of the patch out of context and FUD it.
There's enough uncertainty regarding this track as is without additional
misunderstanding or misrepresentations.

The stuff that is directly relevant to you and your work is the
scheduler changes needed to support RT and the possibility that
it would conflict with the sched domain stuff for NUMA boxes.
The needs are sufficiently different that in the long run something
like "sched-plugin" might be needed to simplify kernel development
and permit branched development.

bill

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/