The reason is that your solution cannot guarantee that the most important
process on my system is not killed, since it does not know what the most
important process on my system is.
> We've had this whole discussion just before the 2.2pre
> era, when I decided the kernel should stabilize and my
> patch wasn't important enough to disturb the debugging.
> I propose we stop this discussion until somebody produces
> better CODE then what's in my patch.
No, we should not stop discussion. And I don't see why you always
think that I think that the code you are proud of should be replaced.
I hope that we can add something to provide a kernel interface (or
whatever) to make reaction to NEAR OOM situations more flexible.
Just imagine that your compute server runs two calculations for NP-hard
problems (you cannot easily guess in advance what the required amount
of data will be); they run for ten days. Then the combined memory requirement
(almost) exceeds your VM size. If one of them gets killed - SHIT! I'd
prefer to stop them both, add a few more MBs of swap space, how ever, and let
one of them continue. If it has finished let the other one continue and
save a few days....
If I had time, I would produce this additional CODE. But, I have not read
much of the kernel sources after the late 0.99s, and I would prefer if
somebody could do it who has more insight. This is why I made the suggestion
in the first place, and this is the reason for the discussion. If, after
the discussion, it is decided that additional flexibility is a Bad Thing(TM)
nobody has to spend time to produce any sort of CODE.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
Please read the FAQ at http://www.tux.org/lkml/