On Sun, 26 Mar 2000, Peter T. Breuer wrote:
>"A month of sundays ago Marco Colombo wrote:"
>> > * Ok, demand-loading was easy, shared pages a little bit tricker. Shared
>> > * pages started 02.12.91, seems to work. - Linus.
>>
>> I don't think the above comment is about overcommitting swap space.
>> He's talking about sharing the text segments of processes, i think.
>> But you should ask Linus, I was not there at the moment (01.12.91) B-).
As I pointed out later, the interesting part is "demand-loading", which
demand-loads both text and data.
>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?
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 don't _actually_ want to use swap myself, and having it there only
>as the "gold-standard" at the back of the IOU seems the best use.
>
>That only leaves malloc and fork overhead as candidates for unexpected
>segfaults. Malloc can be cured by the programmer touching the memory
>when he gets it.
Touching malloc()'ed pages doesn't solve anything -- this is no different
from the case of not touching them immediately, and trying to use them
later. The malloc() still returns a valid pointer but no real memory. If
you then try to touch the memory, what happens when the kernel can't get a
free page?
>Fork overhead is dealt with by having a reserve for the kernel.
Seems like a kludge to me.
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:18 EST