From: Evgeniy Polyakov <zbr@ioremap.net>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Greg KH <greg@kroah.com>,
linux-kernel@vger.kernel.org, dst@ioremap.net,
David Howells <dhowells@redhat.com>
Subject: Re: [4/7] dst: thread pool.
Date: Mon, 19 Jan 2009 20:07:49 +0300 [thread overview]
Message-ID: <20090119170749.GA24775@ioremap.net> (raw)
In-Reply-To: <20090118161041.40608174@infradead.org>
Hi.
On Sun, Jan 18, 2009 at 04:10:41PM -0800, Arjan van de Ven (arjan@infradead.org) wrote:
> > 4: Your "dst thread pool"
>
> from the context... I wouldn't be surprised if this can just use async
> function calls as well... it's simple enough on first sight.
No it can't. Since async function call requires additional allocation
which if failed fallbacks to the sync execution. This defeats the whole
purpose of the kernel thread. And this was already pointed to you Arjan,
but apparently you like to hide this.
Allocation in this path is very dangerous and even in case of atomic one
(which is used in the patch) this is a way heavy and unneded additional
overhead.
So neither DST nor pdflush should use such approach.
Arjan, please update your patch to met the feedback I gave in the
fsdevel mail list and do not allow to sneak the implementation if you do
not like the author :)
The only way to work with your async threads in the described cases is
to have a way to embed the needed event structure into the existing
objects like inode (which will be nacked by the fsdevel community for
reasone) or dst transaction (this may work). But existing size is
actually too big.
--
Evgeniy Polyakov
next prev parent reply other threads:[~2009-01-19 17:08 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-13 23:05 [0/7] Distributed storage for drivers/staging merge request Evgeniy Polyakov
2009-01-13 23:05 ` [1/7] dst: core files Evgeniy Polyakov
2009-01-13 23:05 ` [2/7] dst: network state machine Evgeniy Polyakov
2009-01-13 23:05 ` [3/7] dst: export node Evgeniy Polyakov
2009-01-13 23:05 ` [4/7] dst: thread pool Evgeniy Polyakov
2009-01-13 23:05 ` [5/7] dst: transactions Evgeniy Polyakov
2009-01-13 23:05 ` [6/7] dst: crypto processing Evgeniy Polyakov
2009-01-13 23:05 ` [7/7] dst: kconfig and makefile changes Evgeniy Polyakov
2009-01-13 23:09 ` [8/7] dst: kconfig update Evgeniy Polyakov
2009-01-14 2:22 ` Randy Dunlap
2009-01-14 9:09 ` Evgeniy Polyakov
2009-01-14 2:22 ` [7/7] dst: kconfig and makefile changes Randy Dunlap
2009-01-14 14:46 ` [4/7] dst: thread pool Frederik Deweerdt
2009-01-14 15:01 ` Evgeniy Polyakov
2009-01-15 5:58 ` Andrew Morton
2009-01-15 8:47 ` Evgeniy Polyakov
2009-01-19 0:10 ` Arjan van de Ven
2009-01-19 17:07 ` Evgeniy Polyakov [this message]
2009-02-05 13:55 ` David Howells
2009-01-14 14:52 ` [3/7] dst: export node Jens Axboe
2009-01-14 15:11 ` Evgeniy Polyakov
2009-01-13 23:39 ` [0/7] Distributed storage for drivers/staging merge request Greg KH
2009-01-13 23:47 ` Evgeniy Polyakov
2009-01-14 0:01 ` Greg KH
2009-01-14 0:08 ` Evgeniy Polyakov
2009-01-14 0:12 ` Andrew Morton
2009-01-14 0:15 ` Evgeniy Polyakov
2009-01-14 0:20 ` Evgeniy Polyakov
2009-01-14 0:23 ` Andrew Morton
2009-01-14 0:24 ` Evgeniy Polyakov
2009-01-14 9:39 ` Jeff Garzik
-- strict thread matches above, loose matches on Subject: below --
2008-12-26 11:56 [0/7] Distributed storage release Evgeniy Polyakov
2008-12-26 11:56 ` [1/7] dst: core files Evgeniy Polyakov
2008-12-26 11:56 ` [2/7] dst: network state machine Evgeniy Polyakov
2008-12-26 11:56 ` [3/7] dst: export node Evgeniy Polyakov
2008-12-26 11:56 ` [4/7] dst: thread pool Evgeniy Polyakov
2008-12-17 13:53 [0/7] dst: new release introduction Evgeniy Polyakov
2008-12-17 13:53 ` [1/7] dst: core files Evgeniy Polyakov
2008-12-17 13:53 ` [2/7] dst: network state machine Evgeniy Polyakov
2008-12-17 13:53 ` [3/7] dst: export node Evgeniy Polyakov
2008-12-17 13:53 ` [4/7] dst: thread pool Evgeniy Polyakov
2008-12-17 15:55 ` Arnd Bergmann
2008-12-17 20:03 ` Benjamin Herrenschmidt
2008-12-17 23:32 ` Evgeniy Polyakov
2008-12-18 0:51 ` Benjamin Herrenschmidt
2008-12-18 8:10 ` Evgeniy Polyakov
2008-12-18 9:44 ` Arnd Bergmann
2008-12-17 23:39 ` 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=20090119170749.GA24775@ioremap.net \
--to=zbr@ioremap.net \
--cc=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=dhowells@redhat.com \
--cc=dst@ioremap.net \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.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