Date: Wed, 14 Apr 1999 18:20:03 +0200 From: Ladavac Marino <mladavac@metropolitan.at> To: 'Mikhail Teterin' <mi@kot.ne.mediaone.net>, current@freebsd.org Subject: RE: swap-related problems Message-ID: <55586E7391ACD211B9730000C11002761795EB@r-lmh-wi-100.corpnet.at>
next in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: Mikhail Teterin [SMTP:mi@kot.ne.mediaone.net] > Sent: Wednesday, April 14, 1999 5:01 PM > To: current@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 majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55586E7391ACD211B9730000C11002761795EB>