>By your logic, we should adjust the RSS values of gdb during these
>faults for the debugged task.
Of course no. The fault is generated by gdb and if the fault goes OOM gdb
should be killed as it's the task that is triggering OOM.
But the memory gets allocated in the VM of the traced task, so the RSS of
the traced task must be increased if the page fault needs to allocate
memory.
>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.
And the debugger will tell you anything but a SIGKILL retval. Also what we
are talking about is really not a real life issue. You are not going to
triggered oom by looking at the VM of a traced task. I simply like to do
the obviously safe thing. At that time the traced task is _not_ allocating
memory and so I don't like to kill an innocent.
>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?
This is not going to happen as also the traced task is going to be killed
in the unlikely case you'll trigger oom with gdb in real life.
>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.
Yes because the rule is always been to kill the faulting task and not the
task which has most memory allocated.
>Andreas, what are you smoking?
For the record my name is Andrea and I am not the only one smoking as
2.0.*, 2.1.*, 2.2.* and 2.3.* are all killing the task that triggered the
fault careless if there some process sleeping with a 2g MM allocated.
Andrea
-
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/