Messages in this thread | | | Date | Sat, 20 Nov 1999 22:01:44 -0800 | From | "David S. Miller" <> | Subject | Re: Linux 2.2.14pre7 |
| |
Date: Sun, 21 Nov 1999 03:42:58 +0100 (CET) From: Andrea Arcangeli <andrea@suse.de>
The 2.2.14pre5 behaviour is _very_ intentional.
It's the ptrace task that cause the fault and if something goes OOM then it's _gdb_ and _not_ the innocent ptraced task that must be killed.
I disagree, the task being debugged has incurred a fault, on behalf of gdb.
By your logic, we should adjust the RSS values of gdb during these faults for the debugged task.
Also, if gdb dies, both tasks will most likely wind up getting killed. In such a case, the user has no idea why it happened. However if you kill the debugged task (who is the process consuming all the memory) gdb still lives and the user can see that the subordinate task died and ask the debugger why.
Actually, come to think of it, depending upon the signal disposition of the debugged task at ptrace time, your kill selection could leave gdb dead and the debugged task stuck in SIGSTOP state consuming all of the memory it did before you killed gdb. Does this make any sense, really?
Your argument states that if debugged task X consumes 2GB of ram, and gdb taps in a page of X that puts the system into OOM state, gdb should get killed and we should not kill X which is consuming 2GB of ram.
Andreas, what are you smoking?
Later, David S. Miller davem@redhat.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |