Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 12 Aug 2002 01:21:00 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 12 Aug 2002 01:21:00 -0400 Received: from garrincha.netbank.com.br ([200.203.199.88]:6158 "HELO garrincha.netbank.com.br") by vger.kernel.org with SMTP id ; Mon, 12 Aug 2002 01:20:59 -0400 Date: Mon, 12 Aug 2002 02:24:37 -0300 (BRT) From: Rik van Riel X-X-Sender: riel@imladris.surriel.com To: Andrew Morton cc: Linus Torvalds , lkml Subject: Re: [patch 9/21] batched addition of pages to the LRU In-Reply-To: <3D57449E.4FADF44@zip.com.au> Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org 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 Content-Length: 1059 Lines: 33 On Sun, 11 Aug 2002, Andrew Morton wrote: > And it only takes one dirty block! Any LRU page which is dirty > against a blocked queue is like a hand grenade floating > down a stream [1]. If some innocent task tries to write that > page it gets DoSed via the request queue. This is exactly why we shouldn't wait on dirty pages in the pageout path. Of course we need to wait and we should stall before the system gets overloaded so we don't "run into a wall", but waiting on any random _single_ dirty page just doesn't make sense. Then again, that will probably still not fix the problem that we're not keeping the disk busy so we won't get full writeout speed and end up stalling... regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ - 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/