Because mainline maintainers disagreed. The argument is been "the only
way to avoid suprious oom failures is to reintroduce such infinite
loop". oom deadlocks was the last of my worries (as far as my tree
doesn't deadlock) given the rest of the agreements, so I giveup waiting
somebody to complain (as with everything else it eventually happens when
something can deadlock) and really I've no fun to return discussing
> > 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.
As far I can tell this is the first oom deadlock email I read on l-k
(but I unfortunately don't have time to read every single email on l-k
so I may have missed some). The others were too early deadlocks (less
> > 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
I'm out of sync at the moment, and I've many things pending to do, so
I'm afraid I won't have much time for it.
> 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?
It wasn't a communication problem.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/