Date: Wed, 14 Apr 1999 13:12:00 -0400 (EDT) From: Mikhail Teterin <mi@misha.cisco.com> To: current@freebsd.org Subject: Re: swap-related problems Message-ID: <199904141712.NAA95762@misha.cisco.com> In-Reply-To: <55586E7391ACD211B9730000C11002761795EB@r-lmh-wi-100.corpnet.at> from Ladavac Marino at "Apr 14, 1999 06:20:03 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Ladavac Marino once wrote: > [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). Aha, now its clearer. May be, since we are do not conform anyway, we can design some clever way of notifying a program rather then SIGKILL-ing it? Perhaps, SIGBUS? Something, a program can catch, if it is prepared to, and, may be, do some syscall to find out which chunk of memory can not actually be used by it... -mi 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?199904141712.NAA95762>