Re: RT patch acceptance (scheduler)

[Nick Piggin]

Bill Huey (hui) wrote:
> 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.

Err, no. Please read what was written.

"With multiple disks on a chain, you can see transients that
lock up the CPU in IRQ mode for human-perceptible time,
especially on slower CPUs... "

I was pointing out that this will be a throughput rather than
latency issue. Unless you're saying that an interrupt handler
will run for 30ms or more?

> > 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.

That has nothing to do with what I said. I said ksoftirq doesn't
alleviate latencies.

> > 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. 

It is relevant because code complexity is relevant. Have you
been reading what has been said? Don't take my word for it, read
what Andrew is saying.

> 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.

I haven't looked at *any* part of *any* patch, nor commented on
any patch. I described the type of discussion and acceptance
that needs to happen before a large patch (like this) gets merged.

I also backed up Andrew's assertion that better interrupt latencies
wouldn't really help interactivity (the scheduler is a *far* bigger
factor here)

> 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.

I don't know what you're talking about, sorry.

Why are people so touchy about this subject? I didn't even anywhere
criticize anyone's patches or any approach or idea!! :\

The best way to get anything to happen is to get a common
understanding going through constructive discussion. Please stick to
that. Thanks.
Send instant messages to your online friends http://au.messenger.yahoo.com 
-
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/