From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S264911AbRFUNLx>; Thu, 21 Jun 2001 09:11:53 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S264949AbRFUNLm>; Thu, 21 Jun 2001 09:11:42 -0400
Received: from humbolt.nl.linux.org ([131.211.28.48]:18705 "EHLO
	humbolt.nl.linux.org") by vger.kernel.org with ESMTP
	id <S264911AbRFUNLc>; Thu, 21 Jun 2001 09:11:32 -0400
Content-Type: text/plain; charset=US-ASCII
From: Daniel Phillips <phillips@bonn-fries.net>
To: Marcelo Tosatti <marcelo@conectiva.com.br>,
        Mike Galbraith <mikeg@wen-online.de>
Subject: Re: Linux 2.4.5-ac15
Date: Thu, 21 Jun 2001 15:14:31 +0200
X-Mailer: KMail [version 1.2]
Cc: linux-kernel <linux-kernel@vger.kernel.org>
In-Reply-To: <Pine.LNX.4.21.0106210226330.14247-100000@freak.distro.conectiva>
In-Reply-To: <Pine.LNX.4.21.0106210226330.14247-100000@freak.distro.conectiva>
MIME-Version: 1.0
Message-Id: <01062115143101.00374@starship>
Content-Transfer-Encoding: 7BIT
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Thursday 21 June 2001 07:44, Marcelo Tosatti wrote:
> On Thu, 21 Jun 2001, Mike Galbraith wrote:
> > On Thu, 21 Jun 2001, Marcelo Tosatti wrote:
> > > Ok, I suspect that GFP_BUFFER allocations are fucking up here (they
> > > can't block on IO, so they loop insanely).
> >
> > Why doesn't the VM hang the syncing of queued IO on these guys via
> > wait_event or such instead of trying to just let the allocation fail?
>
> Actually the VM should limit the amount of data being queued for _all_
> kind of allocations.
>
> The problem is the lack of a mechanism which allows us to account the
> approximated amount of queued IO by the VM. (except for swap pages)

Coincidence - that's what I started working on two days ago, and I'm moving 
into the second generation design today.  Look at 'queued_sectors'.  I found 
pretty quickly it's not enough, today I'm adding 'submitted_sectors' to the 
soup.  This will allow me to distinguish between traffic generated by my own 
thread and other traffic.

> > Does failing the allocation in fact accomplish more than what I'm
> > (uhoh:) assuming?
>
> No.
>
> It sucks really badly.

Amen.

--
Daniel