From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 8 Feb 2001 10:35:39 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 8 Feb 2001 10:35:29 -0500 Received: from perninha.conectiva.com.br ([200.250.58.156]:10257 "EHLO perninha.conectiva.com.br") by vger.kernel.org with ESMTP id ; Thu, 8 Feb 2001 10:34:55 -0500 Date: Thu, 8 Feb 2001 11:45:34 -0200 (BRST) From: Marcelo Tosatti To: Ben LaHaise cc: Linus Torvalds , Jens Axboe , Manfred Spraul , Ingo Molnar , "Stephen C. Tweedie" , Alan Cox , Steve Lord , Linux Kernel List , kiobuf-io-devel@lists.sourceforge.net, Ingo Molnar Subject: Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 8 Feb 2001, Marcelo Tosatti wrote: > > On Thu, 8 Feb 2001, Ben LaHaise wrote: > > > > > > (besides, latency would suck. I bet you're better off waiting for the > > > requests if they are all used up. It takes too long to get deep into the > > > kernel from user space, and you cannot use the exclusive waiters with its > > > anti-herd behaviour etc). > > > > Ah, but no. In fact for some things, the wait queue extensions I'm using > > will be more efficient as things like test_and_set_bit for obtaining a > > lock gets executed without waking up a task. > > The latency argument is somewhat bogus because there is no problem to > check the request queue, in the aio syscalls, and simply fail if its full. Ugh, I forgot to say check the request queue before doing any filesystem work. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/