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] [day] [month] [year] [list]

Message-ID: <20061106135435.GA10010@2ka.mipt.ru>
Date:	Mon, 6 Nov 2006 16:54:35 +0300
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Pavel Machek <pavel@....cz>
Cc:	Jonathan Lemon <jlemon@...gsvamp.com>, linux-kernel@...r.kernel.org
Subject: Re: [take22 0/4] kevent: Generic event handling mechanism.

On Mon, Nov 06, 2006 at 01:58:18PM +0100, Pavel Machek (pavel@....cz) wrote:
> Hi!
> 
> > > Can you explain why kevent is better than kqueue?
> > 
> > According to my tests kevent is noticebly faster.
> > It is already too big flag that old system should not be used.
> > And half of my previous mail to you shows why kevent is better/different
> > from kqueue.
> 
> You shown why it is _different_. How much faster is "noticebly
> faster"?

It is different on purpose, don't you think?
If I will put all benchmark results in all mails, no one will read even
half of it.

Here is conlusion section on kevent homepage where FreeBSD kqueue is
compared with kevent (different NIC than recent Linux kevent tests, 
but there are links to old kevent benchamrks there):

"After various sysctls have been changed (sysctl -a output is available
here) things become slightly better (btw, default FreeBSD installation
does not allow such tests at all due to default network parameters), but
number of "connection reset" errors is still very high.
FreeBSD drops too many connections due to either misconfiguration or
lack of resources.

According to FreeBSD and Linux comparison, in Linux number of connection
errors is much smaller than in FreeBSD with comparable or bigger
requests rate."

Briefly saying, FreeBSD kqueue behaves like Linux epoll, sometimes
better (with small request rate), sometimes worse (with 3k simultaneous
connections rate), and the latter was shown to behave worse than kevent.

Actually, Pavel, I do not understand your point. Why do you want to use
*BSD subsystem even if it is impossible to have the same API? You want
me to rewrite kevent so it would look like kqueue, but you did not know
how it looks like, likely you did not know it's API (it uses switches of
commands which are too much frowned upon in Linux kernel), you did not
know what features kevent provides and what is present and what does not
exist in kqueue.
So please point me to the magic Bodhi way which can enlighten me to think 
that completely different system, which works with completely different
OS with completely different API, ABI and kernel internals, should be 
ported to Linux instead of creation new and superior system?
When I become as luminous as you I will go and create new sendfile()
system call which will have the same parameters as BSD. Or not, I will ask
you to do it (actually not, why should we create something new, when
there is BSD system which already has everything we want?).

> 								Pavel

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