Re: [TEST] page tables filling non-highmem

[William Lee Irwin III <wli@holomorphy.com>]

On Mon, Feb 18, 2002 at 02:38:00AM +0100, Andrea Arcangeli wrote:
> My tree doesn't lock up hard even without pte-highmem applied.  The task
> gets killed. 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 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.

Actually I'm a little more skeptical on a second reading:

(1) Which of the 1024 processes will it shoot again?
(2) Where is the OOM trigger again?
(3) Where is the accounting on space usage for page tables again?
(4) What is done to counteract the occcasional unswappable allocation
	satisfied from ZONE_NORMAL exerting pressure over time again?

... and this isn't exactly a report, this is a testcase that takes down
machines without the appropriate fixes on demand in order to provide an
adequate demonstration of how some real-life workloads crash the kernel.

Hopefully I left out enough details to slow down the less ethical people;
if I didn't then I'm willing to hear advice on how to handle these things.
Alan, Linus, if there are recommended methods or fora, please let me know.

If I didn't know of pte-highmem already I would never had posted this in
a public forum until some kind of fix existed.

Also, if there are more blatant bugs like this one waiting for fixes
from your VM patch I would be very interested in getting a list
(privately) so that some kind of effort can be devoted to both pushing
the fixes to mainline and making sure these bugs either don't arise or
get fixed in -rmap.

Please send it encrypted.


Cheers,
Bill