lkml.org 
[lkml]   [2009]   [Jan]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [4/7] dst: thread pool.
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


\
 
 \ /
  Last update: 2009-01-19 18:11    [W:0.078 / U:0.956 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site