Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261824AbUCKXXz (ORCPT ); Thu, 11 Mar 2004 18:23:55 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261804AbUCKXXz (ORCPT ); Thu, 11 Mar 2004 18:23:55 -0500 Received: from fw.osdl.org ([65.172.181.6]:40935 "EHLO mail.osdl.org") by vger.kernel.org with ESMTP id S261824AbUCKXXy (ORCPT ); Thu, 11 Mar 2004 18:23:54 -0500 Date: Thu, 11 Mar 2004 15:25:52 -0800 From: Andrew Morton To: Martin Schwidefsky Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, piggin@cyberone.com.au Subject: Re: blk_congestion_wait racy? Message-Id: <20040311152552.20a9bb06.akpm@osdl.org> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 966 Lines: 22 Martin Schwidefsky wrote: > > > An ouch-per-second sounds reasonable. It could simply be that the CPUs > > were off running other tasks - those timeout are less than scheduling > > quanta. > > I don't understand why an ouch-per-second is reasonable. The mempig is > the only process that runs on the machine and the blk_congestion_wait > uses HZ/10 as timeout value. I'd expect about 100 ouches for the 10 > seconds the test runs. blk_congestion_wait() is supposed to be terminated by someone releasing a disk write request. If no write requests are freed in 100 milliseconds then either Something Is Up or that process simply was not scheduled for some time after the wakeup was delivered. - 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/