Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S270824AbTGPNpY (ORCPT ); Wed, 16 Jul 2003 09:45:24 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S270829AbTGPNpY (ORCPT ); Wed, 16 Jul 2003 09:45:24 -0400 Received: from ns.virtualhost.dk ([195.184.98.160]:27026 "EHLO virtualhost.dk") by vger.kernel.org with ESMTP id S270824AbTGPNpT (ORCPT ); Wed, 16 Jul 2003 09:45:19 -0400 Date: Wed, 16 Jul 2003 16:00:02 +0200 From: Jens Axboe To: Andrea Arcangeli Cc: Alan Cox , Marcelo Tosatti , Chris Mason , lkml , "Stephen C. Tweedie" , Jeff Garzik , Andrew Morton , Alexander Viro Subject: Re: RFC on io-stalls patch Message-ID: <20030716140002.GD833@suse.de> References: <20030715052640.GY833@suse.de> <1058268126.3857.25.camel@dhcp22.swansea.linux.org.uk> <20030715112737.GQ833@suse.de> <20030716124355.GE4978@dualathlon.random> <20030716124656.GY833@suse.de> <20030716125933.GF4978@dualathlon.random> <20030716130442.GZ833@suse.de> <20030716131128.GG4978@dualathlon.random> <20030716132139.GC833@suse.de> <20030716134443.GJ4978@dualathlon.random> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030716134443.GJ4978@dualathlon.random> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2010 Lines: 42 On Wed, Jul 16 2003, Andrea Arcangeli wrote: > On Wed, Jul 16, 2003 at 03:21:39PM +0200, Jens Axboe wrote: > > On Wed, Jul 16 2003, Andrea Arcangeli wrote: > > > On Wed, Jul 16, 2003 at 03:04:42PM +0200, Jens Axboe wrote: > > > > On Wed, Jul 16 2003, Andrea Arcangeli wrote: > > > > > On Wed, Jul 16, 2003 at 02:46:56PM +0200, Jens Axboe wrote: > > > > > > Well it's a combined problem. Threshold too high on dirty memory, > > > > > > someone doing a read well get stuck flushing out as well. > > > > > > > > > > a pure read not. the write throttling should be per-process, then there > > > > > will be little risk. > > > > > > > > A read from user space, dirtying data along the way. > > > > > > it doesn't necessairly block on dirty memory. We even _free_ ram clean > > > if needed, exactly because of that. You can raise the amount of _free_ > > > ram up to 99% of the whole ram in your box to be almost guaranteed to > > > never wait on dirty memory freeing. Of course the default tries to > > > optimize for writeback cache and there's a reasonable margin to avoid > > > writing dirty stuff. the sysctl is there for special usages where you > > > want to never block in a read from userspace regardless whatever the > > > state of the system. > > > > That may be so, but no user will ever touch that sysctl. He just > > experiences what Alan outlined, system grinds to a complete halt. Only > > much later does it get going again. > > and on the small boxes that will happen much less now since on the small > boxes the biggest vm overhead could been generated by the uncontrolled > size of the I/O queue that previously could grow as big as 32M. That is true, however noone runs 32MB boxes anymore :). So I doubt that would be the case. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/