linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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.

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