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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 26 Feb 2007 15:25:22 +0300
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Davide Libenzi <davidel@...ilserver.org>,
	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>,
	Ulrich Drepper <drepper@...hat.com>,
	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: threadlets as 'naive pool of threads', epoll, some measurements

On Mon, Feb 26, 2007 at 12:48:58PM +0100, Ingo Molnar (mingo@...e.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
-
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/