Date: Thu, 29 Jul 2010 10:01:39 -0700 From: mdf@FreeBSD.org To: freebsd-arch@freebsd.org Cc: dwmalone@maths.tcd.ie, alc@freebsd.org, iedowse@freebsd.org Subject: memguard(9) rewrite, part 2 Message-ID: <AANLkTikhJZh3QXZbO0YJcsj%2B2H=HDpTnYgtD9=8hz%2BG4@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Back in March I asked about interest in a memguard(9) redo. I've had the time to get the code to a place I'm pretty happy with, and we've successfully used it at work without running into some of the resource limitations that the original memguard(9) gave. http://people.freebsd.org/~mdf/bsd-memguard.diff The gist of the new implementation is to reserve a lot of KVA for memguard(9) to use, and then to avoid re-using KVA as long as possible. Rather than keep the physical pages around, though, on free(9) the pages are returned to the system. The KVA is allocated using vm_map_findspace() from a current pointer into the memguard_map, which is incremented until the end of the map is encountered, at which time it wraps. This is a "free" way to avoid re-use of KVA as long as possible; any other scheme requires more than O(1) data to track what has been used. I've limited the KVA to 2x ram size, and also limited the physical memory that memguard(9) can take to vm_memguard_divisor fraction of physical memory (instead of limiting both KVA and physical to vm_memguard_divisor as the original code did). This patch also allows for tweaking which malloc type is guarded at run time, will randomly guard allocations of any type if requested, has a knob to always guard allocations of PAGE_SIZE or larger since it won't waste any memory, will optionally add guard pages of unmapped KVA at the beginning and end of the allocation to catch overruns more easily, and also can impose minimum allocation sizes on guarded memory so that the page promotions don't waste too much space. Assuming alc@ is happy with the VM changes and no one has any further suggestions, I'd like to commit this some time next week. I'd also like to MFC to stable/8 and stable/7 since this patch doesn't introduce any KBI/ABI/KPI/API changes. Apart from the general desire to have production systems run as fast as possible, I'd really like more tools like memguard(9) to be always-on, to help catch bugs the first time instead of requiring multiple recreates. Thanks, matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTikhJZh3QXZbO0YJcsj%2B2H=HDpTnYgtD9=8hz%2BG4>