RELENG_4 on flash disk and swap

Kostik Belousov kostikbel at
Tue Mar 14 08:48:23 UTC 2006

On Mon, Mar 13, 2006 at 11:48:06AM -0800, Jon Dama wrote:
> If you feel this situation is undesirable, the first thing to do is to put
> together the patches necessary to allow the kernel to actually track how
> much ram+swap might be needed to cover the address-space allocations
> that have been granted.  This isn't trivial: just start thinking about
> shared allocations, forking, copy-on-writem, etc.
> In order to make this change "costless" I suspect you'll have to hide it
> behind a kernel config option.  Maybe you'll bill it as mere
> instrumentation.
> Then worry about convincing people that overcommit shouldn't be the only
> option.  But once you have your kernel config option to enable proper
> accounting it should be a short-hop to making a sysctl that can disable
> overcommit and enforce limits based on the previously mentioned
> "accounting".
> Most importantly though you won't need to convince anyone that the
> default ought to be changed.
> SIGDANGER has essentially been rejected universally by everyone but its
> creators (IBM), and as it is unusual, don't expect anyone to write a
> program that uses it.  Ditto for any solution that involves madvise or expecting
> programs to prefault their pages.
> Other suggestion: build a time machine to go back to 1990 and get early
> (pages guaranteed) and late (overcommitted) allocation written into POSIX.
> Somewhat accepted is to ensure allocations must be backed but to also
> support a M_NORESERVE flag in mmap to permit overcomitted allocations.
> Anyways, no matter what you must first give the kernel the necessary
> accounting code.
> For the record: I believe in overcommit, but I recognize that it violates
> the semantics people were (foolishly) taught in school.
> Also, when the system is page-starved it kills the largest consumer of
> pages that has the same UID as the process that pushed the system over the
> limit---not merely the largest consumer of pages.  So you see, running
> critical services that carefully pre-allocate and fault their memory is
> possible within the overcommit framework.
>            Jon
I already sent the link to the patch that does exactly this, and did this
countless number of times (and, at least once in this thread):


Patches are ready for testing. But everybody prefer to speak about,
instead of just test and give the feedback. It seems that this matter
is interesting only as soapbox.


More information about the freebsd-stable mailing list