Re: RT patch acceptance
From: Nick Piggin
Date: Wed May 25 2005 - 00:07:16 EST
Sven Dietrich wrote:
Are you serious? Even at 10ms, the monitor refresh rate would
have to be over 100Hz for anyone to "notice" anything,
right?... What sort of numbers are you talking when you say several?
Even without numbers, the IDE IRQ, when run in a thread,
competes with tasks at process level, so that other
tasks can make some progress. Especially if those tasks are
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'm fairly sure this isn't going to happen. Unless you're telling me
that irqs run for 50ms plus.
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.
This is part of the reason why SoftIRQd exists: to act as
a governor for bottom halves that run over and over again.
SoftIRQd handles those bursty bottom halves in task space.
ksoftirq doesn't alleviate any kind of latencies anywhere AFAIKS.
So with that, you already have bottom halves in threads.
softirqs won't normally run in another thread though, right?
Then we are just talking about the concept of running the
top-half in a thread as well.
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 ;)
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/