From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Subject: Re: [take36 10/10] kevent: Kevent based generic AIO. Date: Mon, 12 Feb 2007 13:12:57 +0000 Message-ID: <20070212131257.565f8066@localhost.localdomain> References: <11712796493850@2ka.mipt.ru> <1171279650540@2ka.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Evgeniy Polyakov , David Miller , Ulrich Drepper , Andrew Morton , netdev , Zach Brown , Christoph Hellwig , Chase Venters , Johann Borck , linux-kernel@vger.kernel.org, Jeff Garzik , Jamal Hadi Salim , Ingo Molnar , linux-fsdevel@vger.kernel.org To: Andi Kleen Return-path: In-Reply-To: Sender: netdev-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org > I'm sure others would want them then for their favourite system call combo > too. If they were really useful it might make more sense to have a batch() > system call that works for arbitary calls, but I'm not convinced yet > it's even needed. It would be certainly ugly. batch() would possibly make a lot of sense in terms of the fibril/thread based removal for the need for all the AIO stuff, just to provide a natural way to group and order sequences of synchronous operations into asynchronous groups. I am extremely sceptical about the need for aio_sendfile_path since with sendfile/sendpath hacking around there didn't seem to be much gain. I'm even more sceptical of the header buffer stuff as while other OS's do that as a hack to make TCP packetising work we simply fixed the root problem with TCP_CORK Alan