Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262445AbTFJCAN (ORCPT ); Mon, 9 Jun 2003 22:00:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262459AbTFJCAN (ORCPT ); Mon, 9 Jun 2003 22:00:13 -0400 Received: from 216-42-72-151.ppp.netsville.net ([216.42.72.151]:10409 "EHLO tiny.suse.com") by vger.kernel.org with ESMTP id S262445AbTFJCAJ (ORCPT ); Mon, 9 Jun 2003 22:00:09 -0400 Subject: RE: [PATCH] io stalls From: Chris Mason To: Robert White Cc: Nick Piggin , Andrea Arcangeli , Marc-Christian Petersen , Jens Axboe , Marcelo Tosatti , Georg Nikodym , lkml , Matthias Mueller In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1055211186.23126.422.camel@tiny.suse.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 09 Jun 2003 22:13:07 -0400 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1904 Lines: 50 On Mon, 2003-06-09 at 21:48, Robert White wrote: > From: linux-kernel-owner@vger.kernel.org > [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Nick Piggin > > > Chris Mason wrote: > > > >The major difference from Nick's patch is that once the queue is marked > > >full, I don't clear the full flag until the wait queue is empty. This > > >means new io can't steal available requests until every existing waiter > > >has been granted a request. > > > Yes, this is probably a good idea. > > > Err... wouldn't this subvert the spirit, if not the warrant, of real time > scheduling and time-critical applications? > [ lots of interesting points ] Heh, I didn't really make my goals for the patch clear. They go: 1) quantify the stalls people are seeing with real numbers so we can point at a section of code causing bad performance. 2) Provide a somewhat obvious patch that makes the current __get_request_wait call significantly more fair, in hopes of either blaming it for the stalls or removing it from the list of candidates 3) fix the stalls Most of your suggestions are 2.5 discussion material, where real experimental work is going on. The 2.4 io request wait queue isn't working on priorities, the current one tries to be fair to everyone and provide good throughput to everyone at the same time. It's failing on at least one of those, and until we can fix that I don't even want to think about more complex issues. Current users of the vanilla 2.4 tree will hopefully benefit from a lower latency io request wait queue. The next best thing to real time is a consistently small wait, which is what my patch is trying for. -chris - 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/