Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 6 Feb 2001 18:03:54 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 6 Feb 2001 18:03:44 -0500 Received: from perninha.conectiva.com.br ([200.250.58.156]:49934 "EHLO perninha.conectiva.com.br") by vger.kernel.org with ESMTP id ; Tue, 6 Feb 2001 18:03:27 -0500 Date: Tue, 6 Feb 2001 19:13:59 -0200 (BRST) From: Marcelo Tosatti To: Linus Torvalds cc: Jens Axboe , Manfred Spraul , Ben LaHaise , 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 Tue, 6 Feb 2001, Linus Torvalds wrote: > Remember: in the end you HAVE to wait somewhere. You're always going to be > able to generate data faster than the disk can take it. SOMETHING has to > throttle - if you don't allow generic_make_request() to throttle, you have > to do it on your own at some point. It is stupid and counter-productive to > argue against throttling. The only argument can be _where_ that throttling > is done, and READA/WRITEA leaves the possibility open of doing it > somewhere else (or just delaying it and letting a future call with > READ/WRITE do the throttling). Its not "arguing against throttling". Its arguing against making a smart application block on the disk while its able to use the CPU for other work. An application which sets non blocking behavior and busy waits for a request (which seems to be your argument) is just stupid, of course. - 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/