Re: Avoiding OOM on overcommit...?

From: David Whysong (dwhysong@physics.ucsb.edu)
Date: Fri Mar 31 2000 - 06:07:06 EST


On Fri, 31 Mar 2000, Peter T. Breuer wrote:
>"A month of sundays ago David Whysong wrote:"
>>
>> This whole issue can be easily solved by adding an int to task_struct, a
>
>Well, that's just due to the fact that you have to flag secure
>processes in some way.

Yes, and it's the most direct solution to almost every issue I've seen
raised in all these threads. There is zero runtime overhead. It only uses
4 bytes per task, plus the kernel memory for the OOM killer patch and the
system call. That's cheap compared to the other ideas I've heard, and it
solves the problems _completely_.

>> The modified OOM killer checks each task_struct for the new field, and
>> modifies it's behavior accordingly. When you start a `secure' process,
>> make sure this int is properly set so the kernel won't kill your process
>> unless init is the only remaining alternative.
>
>Given a whole int instead of a bit, one can be more subtle than that!

Of course, I intended the int to be used as a 'task priority' flag, with
some special value (MAXINT?) for secure tasks that should never be killed
under any circumstances. (I don't like calling it 'priority' because that
is easily confused with the 'nice' priority; can anyone suggest a better
name?)

>> In this case, the only time a `secure' process will ever fail is if your
>> machine is HOPELESSLY overloaded AND no non-secure processes are running.
>
>I don't think you got this. No, the secure process cannot fail. The
>accounting guarantees that in this situation the kernel will have
>the room available that it needs for OOM free running.

Um, yes. Sorry about that, I wrote this before I thought of adding the
special "don't-ever-kill-me, my flag is MAXINT" case... this will teach me
to proofread before hitting send.

But you're not quite right either, unless I misunderstand you. There is no
accounting in my scheme; instead each task has this integer in the
task_struct that acts as a priority. This integer is just used as a flag,
typically set at process execution time. I'm not keeping track of memory
use, beyond what the kernel already does.

It is still possible to run the kernel out of memory -- just flag all
tasks as secure and run the system OOM. But nobody in their right mind
would run every task as secure, and only root can assign the task_struct
integer value.

>> The "safe gnumalloc" solution is okay, but wastes memory. The same is true
>
>That is true.
>
>> of stack preallocation. I think it's better to keep overcommit and have
>
>That is not true, but you have misplaced a word: instead of
>"preallocation", you meant "accounting".

You were advocating the allocation of swap space for every stack page.
This wastes a swap page for every stack page in physical RAM. That is at
least 1 page per secure process, and potentially more.

>Overcommit has never been banished.

That depends on who you are talking to in these threads...

Dave

David Whysong dwhysong@physics.ucsb.edu
Astrophysics graduate student University of California, Santa Barbara
My public PGP keys are on my web page - http://www.physics.ucsb.edu/~dwhysong
DSS PGP Key 0x903F5BD6 : FE78 91FE 4508 106F 7C88 1706 B792 6995 903F 5BD6
D-H PGP key 0x5DAB0F91 : BC33 0F36 FCCD E72C 441F 663A 72ED 7FB7 5DAB 0F91

-
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:29 EST