[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CVS: cvs.openbsd.org: src
- To: source-changes_(_at_)_cvs_(_dot_)_openbsd_(_dot_)_org
- Subject: CVS: cvs.openbsd.org: src
- From: Artur Grabowski <art_(_at_)_cvs_(_dot_)_openbsd_(_dot_)_org>
- Date: Tue, 23 Sep 2008 07:25:46 -0600 (MDT)
Module name: src
Changes by: art_(_at_)_cvs_(_dot_)_openbsd_(_dot_)_org 2008/09/23 07:25:46
sys/uvm : uvm_map.c
Do not merge userland map entries.
Imagine lots of random small mappings (think malloc(3)) and sometimes
one large mapping (network buffer). If we've filled up our address space
enough, the random address picked for the large allocation is likely to
be overlapping an existing small allocation, so we'll do a linear scan
to find the next free address. That next free address is likely to
be just after a small allocation. Those two map entires get merged.
If we now allocate an amap for the merged map entry, it will be large.
When we later free the large allocation the amap is not truncated. All
these are design decisions that made sense for sbrk, but with random
allocations and malloc that actually returns memory, this really hurt us.
This is the reason why certain processes like apache and sendmail could
eat more than 10 times as much amap memory as they needed, eventually
hitting the malloc limit and hanging or running the machine out of
kmem_map and crashing.