Re: RT patch acceptance (scheduler)

[hui]

On Wed, May 25, 2005 at 05:00:29PM +1000, Nick Piggin wrote:
> 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... "

ok, yeah, I thought you were talking about something else. Email
is a tricky medium at times.

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

Don't know. For non-DMA IDE access data copies are CPU driven
which can create tons of latency problems for that case. irq-threads
run as SCHED_FIFO and can freeze the system under heavy IO load
in that situation.

The way I interpreted the comment originally was irq-threads suck
which is why these latency happens. This is not what you ment. The
fear here is that there would be a push in the discussion to revert
some of this preemption work away from full preemption to more
conservative techniques like preemption points, which would drive
me absolutely bonkers right now.

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

I reread those comments.

I suggest that you read the patch for the answer to softirq
complexity. You'll find the implementation sane. It's a simple add-on
to how softirqs are handled currently with but pushed all ksoftirqd.
What was non-preemptible execution at the end of an IRQ handler in
the normal kernel is now pushed all to that thread. There's no mystery
magic here.

> 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 interpreted the ksoftirqd comment/worry you said was just that,
inserting a concern about something you percieved as a possible
problem, therefore doubt.

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

This is a complicated problem and I'm not sure what folks are getting
at with the irq latency track other than it exists and it effects
overall latency in the system. Running above the priority of the
irq-thread handlers in a fully preemptible kernel should permit that
thread to run that task and service that thread at hand. Having the
ability to do that *could* help with overall system interactivity,
but it would require proper userspace apps to exploit it.
 
> I don't know what you're talking about, sorry.

I thought you were doing some kind of scheduler CPU NUMA migration
stuff ?

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

Because it's a radical conceptual change to the kernel and this
development group has been classically resistent to these kind of
changes from what I've seen. There's also an insane amount of pressure
from commericial circle to blow this patch out of the water before
inclusion. Just because you haven't seen it yet doesn't mean it's not
going to happen. You can bet that RTOS folks are going to be all over
it in a negative way and they aren't as friendly as you.

Just about everybody in the RTOS works knows this is going to be an
atomic bomb to the industry for better or worse. This is excluding
the freakout nature of the SGI-ish stuff you'll be able to do with
this patch. Just wait until somebody gets a frame locked Doom3 out. :)

> The best way to get anything to happen is to get a common
> understanding going through constructive discussion. Please stick to
> that. Thanks.

Sorry, yeah, I'm a bit jumpy from dealing with chronic irrationality
from the FreeBSD group, which has created low expectations from various
open source groups at times. Interaction with other jumpy kernel
conservatives in this community doesn't the help the matter.

Basically, the more you read http://linuxdevices.com the more you'll
understand why folks are edgy about this. :)

bill

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