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