From owner-freebsd-current  Fri Feb 18 15:59:17 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id 63B9A37BAFE
	for <current@FreeBSD.ORG>; Fri, 18 Feb 2000 15:59:15 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id PAA81991;
	Fri, 18 Feb 2000 15:59:15 -0800 (PST)
	(envelope-from dillon)
Date: Fri, 18 Feb 2000 15:59:15 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200002182359.PAA81991@apollo.backplane.com>
To: alc@cs.rice.edu, current@FreeBSD.ORG
Subject: Re: tentitive complete patch for MAP_GUARDED available
References: <200002182141.QAA18866@pcnet1.pcnet.com> <200002182209.OAA81369@apollo.backplane.com> <200002182304.PAA81713@apollo.backplane.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

    Ok, this time for sure... version 3 of the MAP_GUARDED patch is out.

	http://www.backplane.com/FreeBSD4/
	http://www.backplane.com/FreeBSD4/guard-3.diff
	http://www.backplane.com/FreeBSD4/guard3.c

    MAP_GUARDED

	mmap(addr/NULL, len, prot, MAP_GUARDED, fd, offset)

	The offset field specifies the number of bytes at the base of the 
	returned map which are guarded and should be a multiple of the
	system page size.

	Pages at the end of the map are not guarded (any more).

    MAP_STACK

	Works as per normal except that the per-process stack resource limit
	applies to each mmap() separately.

    MAP_GUARDED|MAP_STACK

	Useful combination to place guard page(s) at the beginning of a 
	thread stack.


    Also in this patch set I optimized vm_map_entry creation during normal
    stack growth operations.  Normally the system tries to chunk vm_map_entry
    allocation for stacks by SGROWSIZ, which is typically 128K.  But
    now the vm_map_entry_insert() optimization is able to optimize standard
    stack growth, which means that the actual vm_map_entry creation is 
    governed by the more generous vm.map_entry_blk_opt value (512K by default).

    I like this implementation a lot better.  By removing the guard pages at
    the end of the map MAP_GUARDED|MAP_STACK operation is much, much more
    intuitive.  You don't have to do a blessed thing to the threading code
    except change MAP_STACK to MAP_STACK|MAP_GUARDED, and bump up the size
    of the mmap() allocation to include what used to be the skipped 'dead'
    page.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message