Messages in this thread | | | Date | Mon, 19 Jan 2009 20:07:49 +0300 | From | Evgeniy Polyakov <> | Subject | Re: [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
| |