Date:	Fri, 23 Feb 2007 21:01:40 +0300
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Davide Libenzi <davidel@...ilserver.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Ulrich Drepper <drepper@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@....com.au>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Zach Brown <zach.brown@...cle.com>,
	"David S. Miller" <davem@...emloft.net>,
	Suparna Bhattacharya <suparna@...ibm.com>,
	Jens Axboe <jens.axboe@...cle.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3

On Fri, Feb 23, 2007 at 09:43:14AM -0800, Davide Libenzi (davidel@...ilserver.org) wrote:
> On Fri, 23 Feb 2007, Evgeniy Polyakov wrote:
> 
> > On Thu, Feb 22, 2007 at 11:46:48AM -0800, Davide Libenzi (davidel@...ilserver.org) wrote:
> > > 
> > > A dynamic pool will smooth thread creation/freeing up by a lot.
> > > And, in my box a *pthread* create/free takes ~10us, at 1000/s is 10ms, 1%. 
> > > Bad, but not so aweful ;)
> > > Look, I'm *definitely* not trying to advocate the use of async syscalls for 
> > > network here, just pointing out that when we're talking about threads, 
> > > Linux does a pretty good job.
> >  
> > If we are going to create 1000 threads each second, then it is better to
> > preallocate them and queue a work to that pool - like syslets did with
> > syscalls, but not ulitimately create a new thread just because it is not 
> > that slow.
> 
> We do create a pool indeed, as I said in the opening of my asnwer. The 
> numbers I posted was just to show that thread creation/destroy is pretty 
> fast, but that does not justify it as a design choice.
 
I was not clear - I meant why do we need to do that when we can run the
same code in userspace? And better if we can have non-blocking dataflows
and number of threads equal to number of processors...
 
> > All such micro-thread designs are especially good in the case when 
> > 1. switching is _rare_ (very)
> > 2. programmer does not want to create complex model to achieve maximum
> > performance
> > 
> > Disk (cached) IO definitely hits first entry and second one is there for
> > advertisements and fast deployment, but overall usage of the
> > asynchronous IO model is not limited to the above scenario, so
> > micro-threads definitely hit own niche, but they can not cover all usage
> > cases.
> 
> You know, I read this a few times, but I still don't get what your point 
> is here ;) Are you talking about micro-thread design in the kernel as for 
> kthreads usage for AIO, or about userspace?
 
I started a week of writing without russian-english dictionary, so
expect some troubles in communications with me :)

I said that about kernel design - when we have thousand(s) of threads,
which do the work - if number of context switches is small (i.e. when
operations mostly do not block), then it is ok (although 'ps' output 
with threads can scary a grandma).
It is also ok to say - 'hey, Linux has so easy AIO model, so that
everyone should switch and start using it and do not care about problems 
associated with multi-threaded programming with high concurrency', 
but, in my opinion, both that cases can not cover all (and most of) 
the usage cases.

To eat my hat (or force others to do the same) I'm preparing a tree for 
threadlet test - I plan to write a trivial web server
(accept/recv/send/sendfile in one threadlet function) and give it a try
soon.

> - Davide
> 

-- 
	Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists