From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "<Andrew Morton" <akpm@osdl.org>,
linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
Christoph Hellwig <hch@infradead.org>,
linuxppc-dev@ozlabs.org, Paul Mackerras <paulus@samba.org>,
containers@lists.osdl.org, Oleg Nesterov <oleg@tv-sign.ru>
Subject: Re: [PATCH] powerpc pseries eeh: Convert to kthread API
Date: Tue, 24 Apr 2007 12:42:24 +1000 [thread overview]
Message-ID: <1177382544.14873.57.camel@localhost.localdomain> (raw)
In-Reply-To: <m1ejmav80l.fsf@ebiederm.dsl.xmission.com>
On Mon, 2007-04-23 at 20:08 -0600, Eric W. Biederman wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>
> >> The only reason for using threads here is to get the error recovery
> >> out of an interrupt context (where errors may be detected), and then,
> >> an hour later, decrement a counter (which is how we limit these to
> >> 6 per hour). Thread reaping is "trivial", the thread just exits
> >> after an hour.
> >
> > In addition, it should be a thread and not done from within keventd
> > because :
> >
> > - It can take a long time (well, relatively but still too long for a
> > work queue)
> >
> > - The driver callbacks might need to use keventd or do flush_workqueue
> > to synchronize with their own workqueues when doing an internal
> > recovery.
> >
> >> Since these are events rare, I've no particular concern about
> >> performance or resource consumption. The current code seems
> >> to work just fine. :-)
> >
> > I think moving to kthread's is cleaner (just a wrapper around kernel
> > threads that simplify dealing with reaping them out mostly) and I agree
> > with Christoph that it would be nice to be able to "fire off" kthreads
> > from interrupt context.. in many cases, we abuse work queues for things
> > that should really done from kthreads instead (basically anything that
> > takes more than a couple hundred microsecs or so).
>
> On that note does anyone have a problem is we manage the irq spawning
> safe kthreads the same way that we manage the work queue entries.
>
> i.e. by a structure allocated by the caller?
Not sure... I can see places where I might want to spawn an arbitrary
number of these without having to preallocate structures... and if I
allocate on the fly, then I need a way to free that structure when the
kthread is reaped which I don't think we have currently, do we ? (In
fact, I could use that for other things too now that I'm thinking of
it ... I might have a go at providing optional kthread destructors).
Ben.
next prev parent reply other threads:[~2007-04-24 2:43 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <m1slawn9eb.fsf@ebiederm.dsl.xmission.com>
[not found] ` <11769695763104-git-send-email-ebiederm@xmission.com>
2007-04-22 12:31 ` [PATCH] powerpc pseries eeh: Convert to kthread API Christoph Hellwig
2007-04-23 20:50 ` Linas Vepstas
2007-04-24 1:38 ` Benjamin Herrenschmidt
2007-04-24 2:08 ` Eric W. Biederman
2007-04-24 2:42 ` Benjamin Herrenschmidt [this message]
2007-04-24 3:20 ` Eric W. Biederman
2007-04-24 4:34 ` Paul Mackerras
2007-04-24 4:51 ` Eric W. Biederman
2007-04-24 5:00 ` Benjamin Herrenschmidt
2007-04-24 5:43 ` Eric W. Biederman
2007-04-24 5:58 ` Benjamin Herrenschmidt
2007-04-24 6:17 ` SOME STUFF ABOUT REISER4 lkml777
2007-04-24 7:46 ` [PATCH] powerpc pseries eeh: Convert to kthread API Cornelia Huck
2007-04-24 17:24 ` Linas Vepstas
2007-04-24 5:55 ` Paul Mackerras
2007-04-24 8:37 ` Christoph Hellwig
2007-04-24 17:35 ` Linas Vepstas
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=1177382544.14873.57.camel@localhost.localdomain \
--to=benh@kernel.crashing.org \
--cc=akpm@osdl.org \
--cc=containers@lists.osdl.org \
--cc=ebiederm@xmission.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=oleg@tv-sign.ru \
--cc=paulus@samba.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;
as well as URLs for NNTP newsgroup(s).