linux-kernel - Re: [take22 0/4] kevent: Generic event handling mechanism.

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]

Message-ID: <20061102080122.GA1302@2ka.mipt.ru>
Date:	Thu, 2 Nov 2006 11:01:22 +0300
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Eric Dumazet <dada1@...mosbay.com>
Cc:	zhou drangon <drangon.mail@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [take22 0/4] kevent: Generic event handling mechanism.

On Thu, Nov 02, 2006 at 08:46:41AM +0100, Eric Dumazet (dada1@...mosbay.com) wrote:
> zhou drangon a écrit :
> >performance is great, and we are exciting at the result.
> >
> >I want to know why there can be so much improvement, can we improve 
> >epoll too ?
> 
> Why did you remove most of CC addresses but lkml ?
> Dont do that please...

Sure, since for example I'm not subscribed (fortunately) to lkml, and I
think you want me to answer the question too...

> Good question :)
> 
> Hum, I think I can look into epoll and see how it can be improved (if 
> necessary)

epoll can not be improved, since the whole polling is designed to have
several layers of dereferencing, kevent simplifies that chain noticebly.

> This is not to say we dont need kevent ! Please Evgeniy continue your work !

I will :)

> Just to remind you that according to 
> http://www.xmailserver.org/linux-patches/nio-improve.html David Libenzi had 
> to wait 18 months before epoll being officialy added into kernel.

kevent exists for about 10 month. We have plenty of time :)

> At that time, many applications were using epoll, and we were patching our 
> kernels for that.
> 
> 
> I cooked a very simple program (attached in this mail), using pipes and 
> epoll, and got 250.000 events received per second on an otherwise lightly 
> loaded machine (dual opteron 246 , 2GHz, 1MB cache per cpu) with 10.000 
> pipes (20.000 handles)

pipes will work with kevent's poll mechanisms only, so there will not be
any performance gain at all since it is essentially the same as epoll
design with waiting and rescheduling (all my measurements with 
epoll vs. kevent_poll always showed the same rates), pipes require the same
notifications as sockets for maximum perfomance.
I've put it into todo list.

> It could be nice to add support for other event providers in this program 
> (AF_INET & AF_UNIX sockets for example), and also add support for kevent, 
> so that we really can compare epoll/kevent without a complex setup.
> I should extend the program to also add/remove sources during lifetime, not 
> only insert at setup time.

If there would exist sockets support, then I could patch it to work with
kevents.

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