Re: threadlets as 'naive pool of threads', epoll, some measurements

[Evgeniy Polyakov <johnpol@2ka.mipt.ru>]

On Mon, Feb 26, 2007 at 12:48:58PM +0100, Ingo Molnar (mingo@elte.hu) wrote:
> 
> yet another performance update - with the fixed 'heaps of stupid 
> threads' evserver_threadlet.c code attached below i got:
> 
> >    evserver_epoll:             9400 reqs/sec
> >    evserver_epoll_threadlet:   9400 reqs/sec
> 
>      evserver_threadlet:         9000 reqs/sec
> 
> so the overhead, instead of the 10x slowdown Evgeniy predicted/feared, 
> is 4% for this particular, very event-centric workload.
> 
> why? because Evgeniy still overlooks what i've mentioned so many times: 
> that there is lots of inherent 'caching' possible even in this 
> particular '8000 clients' workload, which even the most stupid threadlet 
> queueing model is able to take advantage of. The maximum level of 
> parallelism that i've measured during this test was 161 threads.

:)

I feared _ONLY_ situation when thousands of thereads are eating my brain
- so case when 161 threads are running simultanesoulsy is not that bad
compared to what micro-design can do (of its best/worst) at all!

So, caching is good - threadlets do not spawn a new thread, kevent
returns immediately, but in case of things are not that shine -
threadlets spawnd a new thread, while kevent process next request or
waits for all completed.

I'm a bit stuck right now with my benchmarks - intel core2 machine
requires reinstallation (it is installed for amd64 arch of debian
testing and admins at paid work setup my internet connection
down to miserable bytes per second (who said that hacked/social
engineered 1mb/sec can live forever?), so expect it tomorrow), 
via epia one is under stress testing right now.

> 	Ingo

-- 
	Evgeniy Polyakov