mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjan@infradead.org>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
	Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Lai Jiangshan <laijs@cn.fujitsu.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [RFC][PATCH] create workqueue threads only when needed
Date: Sun, 1 Feb 2009 09:04:29 -0800	[thread overview]
Message-ID: <20090201090429.0c7e1362@infradead.org> (raw)
In-Reply-To: <4985CC57.7090800@s5r6.in-berlin.de>

On Sun, 01 Feb 2009 17:22:47 +0100
Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:

> > I don't know, most of those I've looked on are not documented about
> > the reason for a private workqueue. I guess most of them can use
> > the usual kevent.
> 
> I have stuff in drivers/firewire/ done in a private workqueue and some
> in the shared workqueue which I will eventually move either into
> short-lived ad hoc created kthreads /or/ preferably into a thread pool
> implementation --- if such a thing will have found its way into the
> kernel when I have time for my project.
> 
> I need to get callers of scsi_add_device and scsi_remove_device out of
> the picture.

what are the requirements for you to do this?

right now, the async calls are "fire and forget... but you can wait for
completion". The "price" is that the code needs to allocate a little
bit of memory for management overhead. The second price then is that 
if this allocation fails, the code needs to run "in context".

Would this be a problem?

I can add a variant of the API where you pass in some memory of your
own, which then does not fail. (but also won't get freed automatically
etc)



-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

  reply	other threads:[~2009-02-01 17:04 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-27  0:17 Frederic Weisbecker
2009-01-27  0:30 ` Arjan van de Ven
2009-01-31 18:03   ` Frederic Weisbecker
2009-01-31 18:15     ` Arjan van de Ven
2009-01-31 18:28       ` Frederic Weisbecker
2009-02-01 16:22         ` Stefan Richter
2009-02-01 17:04           ` Arjan van de Ven [this message]
2009-02-01 17:40             ` Stefan Richter
2009-02-01 17:47               ` Arjan van de Ven
2009-02-01 18:06                 ` Stefan Richter
2009-02-01 18:11                   ` Arjan van de Ven
2009-02-01 21:37         ` Benjamin Herrenschmidt
2009-02-02  2:24           ` Frederic Weisbecker
2009-02-02  6:00             ` Benjamin Herrenschmidt
2009-02-02  8:42               ` Stefan Richter
2009-02-02  9:05                 ` Benjamin Herrenschmidt
2009-02-02  9:14                   ` Oliver Neukum
2009-02-02  9:46                     ` Benjamin Herrenschmidt
2009-02-02  9:58                       ` Peter Zijlstra
2009-02-02 10:03                       ` Oliver Neukum
2009-02-02 20:44                         ` Benjamin Herrenschmidt
2009-02-04  9:54                           ` Oliver Neukum
2009-02-02 11:39                     ` Stefan Richter
2009-02-02 11:32                 ` Frederic Weisbecker
2009-02-02 11:26               ` Frederic Weisbecker
2009-02-02  5:19           ` Arjan van de Ven
2009-02-02  6:01             ` Benjamin Herrenschmidt
2009-02-02  9:01             ` Stefan Richter
2009-02-02 14:45               ` Arjan van de Ven
     [not found] ` <20090126162807.1131c777.akpm@linux-foundation.org>
2009-01-27  1:46   ` Oleg Nesterov
2009-01-27  8:40     ` Frederic Weisbecker
2009-01-27  3:07 ` Alasdair G Kergon
2009-01-27  8:57   ` Frederic Weisbecker
2009-01-27 12:43     ` Ingo Molnar
2009-02-02 14:49 ` Daniel Walker
2009-02-02 14:51   ` Frédéric Weisbecker
2009-02-02 15:40     ` Daniel Walker

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=20090201090429.0c7e1362@infradead.org \
    --to=arjan@infradead.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=fweisbec@gmail.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    --cc=stefanr@s5r6.in-berlin.de \
    /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

Powered by JetHome