On Mon, 27 Mar 2000, Peter T. Breuer wrote:
>"A month of sundays ago David Whysong wrote:"
>>[ptb wrote]
>> >And I arrived later too. But while we're on the subject of swap space,
>> >doesn't "reserve me 8MB of disk-based swap as backing for my stack" cure
>> >everyones OOM blues? I propose that that's a fair use for swap nowadays.
>>
>> I don't know; what happens now if you use more than 8 MB of stack? Do "bad
>> things" happen, or does the kernel grow the stack?
>
>I don't believe you can grow beyond your rlimit.
Yes, although you can increase your rlimit.
I just wrote a little recursive program to explore stack behavior. It's
amazing how much programming a person can do while still not learning a
lot of little details about the underlying system. :-) I've learned a lot
in the past week or two...
>I also think that you start off with less stack than that and libc
>or stuff embedded in your code by gcc makes sbrk() calls to grow the
>stack up to your rlimit as necessary.
Yes, I'm something like this must happen. Otherwise every process would
have a vsize of at least 8 megs.
>> If the stack can grow, this doesn't really help. And I'm not sure I like
>> the idea anyway; it's like optimizing for the worst case instead of the
>> common case.
>
>I am suggesting only that programs/systems which need guarantees start up
>with real swap space backing processes stacks.
Ok, so you aren't doing away with overcommit entirely, just trying to
guarantee memory for one process. Makes sense... but the same old problem
still exists if some other task runs the system out of memory. And since
the stack still dynamically grows, you have to make sure that you never
use more than the preallocated backing store.
Is that right?
>Yes it is. The touch will cause a segfault if there is no memory.
>Since this happens in your malloc wrapper, you can return 0 and handle
>that in the normal program. (ahem .. you better already had the stack
>required for the segv handler in the wrapper).
Ah, the light dawns! This makes sense, and seems like a pretty good
solution to the problem. You can reserve memory for your program, but not
at the expense of the rest of the system!
FINALLY someone comes up with a solution to the malloc() return value
issue. And it's one that I can live with -- and entirely in user-space,
even! :-) And you don't force all tasks to use it.
It's not enough to make Linda Walsh happy, but I think it's pretty good.
Not that I would use it myself, I'm pretty happy with current behavior
(with Rik's patch) and "echo 1 > /proc/sys/vm/overcommit_memory". But I
seem to be in the minority...
>You get a segfault at the time of the malloc call, instead of later.
>The wrapper will handle it. Ummm .. you can guarantee stack space for
>the handler by using longjmp just before you call malloc in the
>wrapper I vaguely see.
I'll take your word for it.
>> >Fork overhead is dealt with by having a reserve for the kernel.
>>
>> Seems like a kludge to me.
>
>The latter is, but I believe that's the way things are now.
>
>Requiring swap backing for a processes stack is not a kludge.
Yes, the kludge comment was referring to the reserve for fork.
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:19 EST