Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S293501AbSBRBz0>; Sun, 17 Feb 2002 20:55:26 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S293502AbSBRBzR>; Sun, 17 Feb 2002 20:55:17 -0500
Received: from dsl-213-023-043-245.arcor-ip.net ([213.23.43.245]:16520 "EHLO
	starship.berlin") by vger.kernel.org with ESMTP id <S293501AbSBRBzN>;
	Sun, 17 Feb 2002 20:55:13 -0500
Content-Type: text/plain; charset=US-ASCII
From: Daniel Phillips <phillips@bonn-fries.net>
To: Andrea Arcangeli <andrea@suse.de>,
        Marcelo Tosatti <marcelo@conectiva.com.br>
Subject: Re: [TEST] page tables filling non-highmem
Date: Mon, 18 Feb 2002 02:59:26 +0100
X-Mailer: KMail [version 1.3.2]
Cc: William Lee Irwin III <wli@holomorphy.com>, linux-kernel@vger.kernel.org,
        rsf@us.ibm.com
In-Reply-To: <20020215045106.GB26322@holomorphy.com> <E16beDZ-0002jy-00@starship.berlin> <20020218023800.A23743@athlon.random>
In-Reply-To: <20020218023800.A23743@athlon.random>
MIME-Version: 1.0
Content-Transfer-Encoding: 7BIT
Message-Id: <E16cd5S-0000Ij-00@starship.berlin>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On February 18, 2002 02:38 am, Andrea Arcangeli wrote:
> On Fri, Feb 15, 2002 at 09:59:45AM +0100, Daniel Phillips wrote:
> > On February 15, 2002 05:51 am, William Lee Irwin III wrote:
> > > The following testcase brought down 2.4.17 mainline on an
> > > 8-way P-III 700MHz machine with 12GB of RAM. The last thing
> > > logged from it was a LowFree of 2MB with 9GB of highmem free
> > > after something like 6-8 hours of pounding away, at which
> > > time the machine stopped responding (IIRC it was given ~12
> > > hours to echo another character).
> > > 
> > > This testcase is a blatant attempt to fill the direct-mapped
> > > portion of the kernel virtual address space with process pagetables.
> > > It was suspected such a thing was happening in another failure scenario
> > > which is what motivated me to devise this testcase. I believe a fix
> > > already exists (i.e. aa's ptes in highmem stuff) though I've not yet
> > > verified its correct operation here.
> > 
> > As you described it to me on irc, this demonstration turns up a
> > considerably worse problem than just having insufficient space for
> > page tables - the system locks up hard instead of doing anything
> > reasonable on page table-related oom.  It's wrong that the system
> > should behave this way, it is after all, just an oom.
> > 
> > Now that basic stability issues seem to be under control, perhaps
> > it's time to give the oom problem the attention it deserves?
> 
> My tree doesn't lock up hard even without pte-highmem applied.  The task
> gets killed.

Well, the obvious question is: Why Isn't It In Mainline???

> backout pte-highmem, try the same testcase again on my tree
> and you'll see. The oom handling in mainline is deadlock prone, I always
> known this and that's why I always rejected it. Nobody but me
> acklowledged this problem

Lots of people acknowleged it, it seems just one guy fixed it.

> and I spent quite an amount of time convincing
> mainline maintainers about those deadlock flaws of the mainline approch
> but I failed so I giveup waiting for a report like this, just like with
> all the other stuff that is now in my vm patch, 90% of it I tried to
> push it separately into mainline before having to accumulate it.

What I'd suggest is, just post a list of each item outstanding item that
haven't been pushed to mainline, and an explanation of which problem it
fixes.

Incorrect oom accounting has been a bleeding wound for well over a year,
and if you've got a fix that's provably correct...

Marcelo??  Is this just a stupid communication problem?

-- 
Daniel
-
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/