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:	Wed, 30 May 2007 15:02:37 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	Zach Brown <zach.brown@...cle.com>, 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>,
	Evgeniy Polyakov <johnpol@....mipt.ru>,
	"David S. Miller" <davem@...emloft.net>,
	Suparna Bhattacharya <suparna@...ibm.com>,
	Davide Libenzi <davidel@...ilserver.org>,
	Jens Axboe <jens.axboe@...cle.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: Syslets, Threadlets, generic AIO support, v6


* Jeff Garzik <jeff@...zik.org> wrote:

> >>You should pick up the kevent work :)
> >
> >3 months ago i verified the published kevent vs. epoll benchmark and 
> >found that benchmark to be fatally flawed. When i redid it properly 
> >kevent showed no significant advantage over epoll. Note that i did 
> >those measurements _before_ the recent round of epoll speedups. So 
> >unless someone does believable benchmarks i consider kevent an 
> >over-hyped, mis-benchmarked complication to do something that epoll 
> >is perfectly capable of doing.
> 
> You snipped the key part of my response, so I'll say it again:
> 
> Event rings (a) most closely match what is going on in the hardware 
> and (b) often closely match what is going on in multi-socket, 
> event-driven software application.

event rings are just pure data structures that describe a set of data, 
and they have advantages and disadvantages. For the record, we've 
already got direct experience with rings as software APIs: they were 
used for KAIO and they were an implementational and maintainance 
nightmare and nobody used them. Kevent might be better, but you make it 
sound as if it was a trivial design choice while it certainly isnt!

Sure, for hardware interfaces like networking cards tx and rx rings are 
the best thing but that is apples to oranges: hardware itself is about 
_limited_ physical resources, matching a _limited_ data structure like a 
ring quite well. But for software APIs, the built-in limit of rings 
makes it a baroque data structure that has a fair share disadvantages in 
addition to its obvious advantages.

> This is not something epoll is capable of doing, at the present time.

epoll is very much is capable of doing it - but why bother if something 
more flexible than a ring can be used and the performance difference is 
negligible? (Read my other reply in this thread for further points.)

but, for the record, syslets very much use a completion ring, so i'm not 
fundamentally opposed to the idea. I just think it's seriously 
over-hyped, just like most other bits of the kevent approach. (Nor do we 
have to attach this to syslets and threadlets - kevents are an 
orthogonal approach not directly related to asynchronous syscalls - 
syslets/threadlets can make use of epoll just as much as they can make 
use of kevent APIs.)

	Ingo
-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ