"A month of sundays ago David Whysong wrote:"
> On Fri, 24 Mar 2000, Peter T. Breuer wrote:
> >"A month of sundays ago David Whysong wrote:"
> >>
> >> It seems to me that this whole overcommit debate is just avoiding the real
> >> problem, which is how to decide which tasks to kill.
>
> >Kill the process with the youngest non-init ancestor. Use login-shells
> >as primal ancestors. If a system daemon goes wonky, that;s the system's
> >business.
>
> I'd rather just use a daemon in conjunction with Rik van Riel's patch (see
> the email I just sent to LKML). This keeps policy in user-space, while
> making the kernel robust against OOM situations.
>
> What you describe would work, but it would also make some very vocal
> people unhappy...
I'll cc: 'em :-).
> >This may require you to track the ancestry of a process in the process
> >table. This requires more that 16 bit pids. Also needs a pid "generation"
> >counter.
>
> Can't you just keep following ppid? (Sorry if this is stupid, I'm not
> really a systems programmer...)
You're doing very well. The parent of the process may have disappeared
so you won't be able to trace it back in the way you suggest.
It might actually be possible nowadays to provide backing space on disk for the
stacks of live processes. Nearly everyone will have 2GB spare for 256*8MB
of emergency stack space. That about takes care of everyones problems,
since not walking malloced memory when you get it to make sure its
there is the programmers decision.
Peter
-
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/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:17 EST