Re: RT patch acceptance

[Nick Piggin]

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
> high priority.
>
> 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/