[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061106103724.GA4535@2ka.mipt.ru>
Date: Mon, 6 Nov 2006 13:37:24 +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 11:16:33AM +0100, Pavel Machek (pavel@....cz) wrote:
> On Mon 2006-11-06 13:13:29, Evgeniy Polyakov wrote:
> > On Sun, Nov 05, 2006 at 09:47:41PM +0100, Pavel Machek (pavel@....cz) wrote:
> > > It has been show in this thread that kevent is too different to kqueue
> > > as is... but what are the advantages of kevent? Perhaps we should use
> > > kqueue on Linux, too (even if it means one more rewrite for you...?)
> >
> > Should we use *BSD VMM system when we have superiour Linux one?
>
> Very different question; VMM system is not something that has userland
> API.
So what? We still create new things, which work better than old ones
even if it requires 'to reinvent the wheel'.
It was shown too many times already why kqueue api can not be used in
Linux.
Btw, if you want someone to rewrite something, you can start with mmaped
based malloc for example. Why don't you want to do it - although API is
the same, but underlying logic is different.
> 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.
--
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/
Powered by blists - more mailing lists