[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070530085159.GC21528@2ka.mipt.ru>
Date: Wed, 30 May 2007 12:51:59 +0400
From: Evgeniy Polyakov <johnpol@....mipt.ru>
To: Ingo Molnar <mingo@...e.hu>
Cc: Ulrich Drepper <drepper@...hat.com>, Jeff Garzik <jeff@...zik.org>,
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>,
"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
On Wed, May 30, 2007 at 10:42:52AM +0200, Ingo Molnar (mingo@...e.hu) wrote:
> it is a serious flexibility issue that should not be ignored. The
> unified fd space is a blessing on one hand because it's simple and
> powerful, but it's also a curse because nested use of the fd space for
> libraries is currently not possible. But it should be detached from any
> fundamental question of kevent vs. epoll. (By improving library use of
> file descriptors we'll improve the utility of all syscalls - by ducking
> to a memory based API we only solve that particular event based usage.)
There is another issue with file descriptors - userspace must dig into
kernel each time it wants to get a new set of events, while with memory
based approach it has them without doing so. After it has returned from
kernel and know that there are some evetns, kernel can add more of them
into the ring (if there is a place) and userspace will process them
withouth additional syscalls.
Although syscall overhead is very small, it does exist and should not be
ignored in the design.
>
> 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/
Powered by blists - more mailing lists