![]() | |||||||||||
Messages in this thread |
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
| ||||||||||
| Last update: 2005-05-25 09:15 [from the cache] ©2003-2008 | |||||||||||