From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
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: Thu, 03 Jul 2008 07:02:53 +1000 [thread overview]
Message-ID: <1215032573.21182.59.camel@pasglop> (raw)
In-Reply-To: <20080702200047.GA385@goodmis.org>
On Wed, 2008-07-02 at 16:00 -0400, Steven Rostedt wrote:
>
> As for interrupt threads, those would help for some non-RT issues
> (having a better desktop feel) but not for the issue that Ben has been
> stating. I would be interested in knowing exactly what is needing to
> handle a page fault inside the kernel. If we need to do something for a
> user space task, as soon as that task is found the work should be passed
> to that thread.
Not much is needed, as the mm is passed as an argument to
handle_mm_fault(). Page faults can already be handled by 'other'
processes (get_user_pages() doesn't have to be called in the context of
the target mm). I need to check if we may not get into funky issues down
at the vfs level if using a kernel thread without files and I may need
to dbl check if anything in that path tries to signal but that's about
it afaik.
Ben.
next prev parent reply other threads:[~2008-07-02 21: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
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 [this message]
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=1215032573.21182.59.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=arjan@linux.intel.com \
--cc=jk@ozlabs.org \
--cc=ksummit-2008-discuss@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.