public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: benh@kernel.crashing.org
Cc: Arjan van de Ven <arjan@linux.intel.com>,
	ksummit-2008-discuss@lists.linux-foundation.org,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	Jeremy Kerr <jk@ozlabs.org>
Subject: Re: [Ksummit-2008-discuss] Delayed interrupt work, thread pools
Date: Wed, 02 Jul 2008 13:02:50 +0200	[thread overview]
Message-ID: <87zlp0sg4l.fsf@basil.nowhere.org> (raw)
In-Reply-To: <1214977447.21182.33.camel@pasglop> (Benjamin Herrenschmidt's message of "Wed, 02 Jul 2008 15:44:07 +1000")

Benjamin Herrenschmidt <benh@kernel.crashing.org> 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 


  reply	other threads:[~2008-07-02 11:03 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-01 12:45 Delayed interrupt work, thread pools Benjamin Herrenschmidt
2008-07-01 12:53 ` [Ksummit-2008-discuss] " Matthew Wilcox
2008-07-01 13:38   ` Benjamin Herrenschmidt
2008-07-01 13:02 ` Robin Holt
2008-07-02  1:39   ` Dean Nelson
2008-07-02  2:38     ` Benjamin Herrenschmidt
2008-07-02  2:47       ` Dave Chinner
2008-07-02 14:27       ` [Ksummit-2008-discuss] " Hugh Dickins
2008-07-02  4:22 ` Arjan van de Ven
2008-07-02  5:44   ` Benjamin Herrenschmidt
2008-07-02 11:02     ` Andi Kleen [this message]
2008-07-02 11:19       ` Leon Woestenberg
2008-07-02 11:24         ` Andi Kleen
2008-07-02 20:57       ` Benjamin Herrenschmidt
2008-07-02 14:11     ` James Bottomley
2008-07-02 20:00       ` Steven Rostedt
2008-07-02 20:22         ` James Bottomley
2008-07-02 20:28           ` Arjan van de Ven
2008-07-02 20:40           ` Steven Rostedt
2008-07-02 21:02         ` Benjamin Herrenschmidt
2008-07-02 21:00       ` Benjamin Herrenschmidt
2008-07-03 10:12         ` Eric W. Biederman
2008-07-03 10:31           ` Benjamin Herrenschmidt
2008-07-07 14:09       ` Chris Mason
2008-07-07 23:03         ` Benjamin Herrenschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zlp0sg4l.fsf@basil.nowhere.org \
    --to=andi@firstfloor.org \
    --cc=arjan@linux.intel.com \
    --cc=benh@kernel.crashing.org \
    --cc=jk@ozlabs.org \
    --cc=ksummit-2008-discuss@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox