This deals with a mmap+fork bomb that can cause the kernel to
eat all of KVM in vm_map_entry structures. The default limit
should be set generously enough for people using the current
FreeBSD threads incarnation (and isn't an issue w/ linux
threads due to rfork resulting in
* Matthew Dillon [EMAIL PROTECTED] [000216 16:05] wrote:
It is possible to fix the problem. We can add a new mmap() flag which
we call MAP_GUARDED which would basically be an anonymous mmap() which
implements a special case in vm_fault. This pager is designed to always
On Wed, Feb 16, 2000 at 01:18:13PM -0800, Matthew Dillon wrote:
This deals with a mmap+fork bomb that can cause the kernel to
eat all of KVM in vm_map_entry structures. The default limit
should be set generously enough for people using the current
FreeBSD threads incarnation
On Wed, Feb 16, 2000 at 02:13:39PM -0800, Jason Evans wrote:
On Wed, Feb 16, 2000 at 01:18:13PM -0800, Matthew Dillon wrote:
This deals with a mmap+fork bomb that can cause the kernel to
eat all of KVM in vm_map_entry structures. The default limit
should be set generously
: This deals with a mmap+fork bomb that can cause the kernel to
: eat all of KVM in vm_map_entry structures. The default limit
: should be set generously enough for people using the current
: FreeBSD threads incarnation (and isn't an issue w/ linux
: threads due to
On Wed, Feb 16, 2000 at 03:33:58PM -0800, Matthew Dillon wrote:
Is anyone interested in me doing this for the 4.0 release? It would
help both our current threads model and the linux threads model a lot.
I can do it in a day and it should be trivial to test, the modifications
:On Wed, Feb 16, 2000 at 03:33:58PM -0800, Matthew Dillon wrote:
: Is anyone interested in me doing this for the 4.0 release? It would
: help both our current threads model and the linux threads model a lot.
: I can do it in a day and it should be trivial to test, the modifications
:
:I believe that I can fix the downward-trending optimization problem
:but it's more work then I have time for right now. Please check out
:the patch and tell me what you think.
I take it back. It turns out that fixing the downward-trending h
optimization is trivial. Well,