Re: [Ksummit-2008-discuss] Delayed interrupt work, thread pools

[Andi Kleen]

Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> writes:

>> how much of this would be obsoleted if we had irqthreads ?
>
> I'm not sure irqthreads is what I want...
>
> First, can they call handle_mm_fault ? (ie, I'm not sure precisely what
> kind of context those operate into).

Interrupt threads would be kernel threads and kernel threads
run with lazy (= random) mm and calling handle_mm_fault on that
wouldn't be very useful because you would affect a random mm.

Ok you could force them to run with a specific MM, but that would
cause first live time issues with the original MM (how could you
ever free it?) and also increase the interrupt handling latency
because the interrupt would be a nearly full blown VM context
switch then.

I also think interrupts threads are a bad idea in many cases because
their whole "advantage" over classical interrupts is that they can
block. Now blocking can be usually take a unbounded potentially long
time.

What do you do when there are more interrupts in that unbounded time?

Create more interrupt threads?  At some point you'll have hundreds
of threads doing nothing when you're unlucky.

Keep the interrupt event blocked? Then you'll not be handling
any events for a long time.

The usual Linux design that you design that interrupt to be fast
and run in a bounded time seems far more sane to me.

RT Linux has interrupt threads and they work around this problem
by assuming that the block events are only short (only 
what would be normally spinlocks).  If someone took a lock there
long enough then the bad things described above would happen.

Given if a spinlock is taken too long then a non RT kernel
is usually also not too happy so it's usually ensured that
that this is not the case.

But for your case these guarantees (only short lock regions 
block) would not be the case (handle_mm_fault can block for 
a long time in some cases) and then all hell could break lose.

So in short I don't think interrupts are a solution to your
problem or that they even solve any problem in a non RT kernel.

-Andi 

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