From: Arjan van de Ven <arjan@infradead.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
mingo@elte.hu, Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Subject: Re: [PATCH] fastboot: Introduce an asynchronous function call mechanism
Date: Wed, 15 Oct 2008 07:52:46 -0400 [thread overview]
Message-ID: <20081015075246.2e1610f3@infradead.org> (raw)
In-Reply-To: <20081015014117.faff3a61.akpm@linux-foundation.org>
On Wed, 15 Oct 2008 01:41:17 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> > +static int async_active = 0;
>
> ?
ok will add comment
>
> Please talk to Evgeniy about his new thread_pool stuff which I've
> suggested become a generic library.
>
> (looks at changelog, doesn't really understand the need for the
> thread pool thing, doesn't understand the comment about device
> numbers)
it's very simple. Take the case of doing each sata port probe as an
asynchronous item. In order to keep a stable device naming/ordering,
all the sata probes need to be done in sequence, but, say, the USB
probing can be done in parallel. This means that we need to assign the
various async tasks to specific pools (based on which device number
space they will put devices in) and can't just arbitrarily spawn them
to arbitrary threads.
>
> > +
> > +void call_async(int pool_number, int argc, ...)
>
> This looks like schedule_work(). Why cannot that be used (perhaps
> after suitable modification)?
as I said in the comments... the object lifetimes don't work.
We need to be able to schedule one per sata port (as per Linus'
suggest) which means we need a new work struct per function call. And
then we need something that garbage collects these, now dynamically
allocated, work structs. Which work queues just don't do. If you make
them do that... you end up with the code I wrote.
>
>
>
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
next prev parent reply other threads:[~2008-10-15 11:52 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-12 23:44 [PATCH] fastboot: Introduce an asynchronous function call mechanism Arjan van de Ven
2008-10-12 23:45 ` async function call test users Arjan van de Ven
2008-10-13 7:22 ` Ingo Molnar
2008-10-13 3:44 ` [PATCH] fastboot: Introduce an asynchronous function call mechanism Willy Tarreau
2008-10-13 7:15 ` Pekka Enberg
2008-10-13 14:45 ` Arjan van de Ven
2008-10-15 8:41 ` Andrew Morton
2008-10-15 10:37 ` Evgeniy Polyakov
2008-10-15 11:52 ` Arjan van de Ven [this message]
2008-10-15 12:30 ` Alan Cox
2008-10-15 16:59 ` Andrew Morton
2008-10-15 17:52 ` Alexey Dobriyan
2008-10-15 17:55 ` Roland Dreier
2008-10-15 18:09 ` Alexey Dobriyan
2008-10-15 18:09 ` Andrew Morton
2008-10-15 20:23 ` Arjan van de Ven
2008-10-15 21:18 ` Evgeniy Polyakov
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=20081015075246.2e1610f3@infradead.org \
--to=arjan@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=johnpol@2ka.mipt.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=torvalds@linux-foundation.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