Re: RT patch acceptance (scheduler)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux