> -----Original Message-----
> From: Mikhail Teterin [SMTP:m...@kot.ne.mediaone.net]
> Sent: Wednesday, April 14, 1999 5:01 PM
> To: curr...@freebsd.org
> Subject: Re: swap-related problems
>
> They then, rightfully exclaimed:
>
> . but should not malloc() have returned me NULL?
>
> And the rest is drowned in the explanations of why it is very hard to
> assure.
> I'm repeating myself here and so do others. We are probably facing the
> major
> disadvantange of the "overcommit" strategy, and there may not, indeed,
> be a
> way around this.
>
[ML] Short of disabling memory overcommit, no there is no
answer. If you do disable overcommit, prepare to add humongous swap
areas (or maybe not--some unices reserve the pages in the filesystem,
stealing the free blocks, so to say, but write the dirty pages to the
swap partitions. They also keep 2 counters: swap pages reserved, and
swap pages actually used. They are capable of swapping into a
filesystem should the need actually arise, but are very inefficient in
doing so. However, having both numbers--swap reserved and swap
used--allows the sysadmin to properly size the swap partitions).
> Documenting this properly is what is definitely in order...
>
[ML] I would agree to this. Perhaps in the IMPLEMENTATION
section of the corresponding manpages (malloc, s/brk, fork.)
> While we are at this, what is the right way to find out if the
> returned pointer
> can be used?
>
[ML] Sadly, in the memory overcommit situation, there is no way
to know whether a pointer returned by malloc will cause a process demise
or not. The pointer is valid, but the swap area mapping is defered
until the page is dirtied (basically, the pointer points to a readonly
zero filled physical page and on write the trap handler tries to
allocate a backing swap area for the page. If the swap is exhausted,
the handler eventually fails. What the system does at this time is
irrelevant.
Please note that memory overcommit architectures are a rather
common optimization; FreeBSD is one of them. They do, however, break
the ISO/ANSI C conformance (strictly speaking).
/Marino
> -mi
>
>
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
