Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 5 Jan 2017 09:13:21 -0800
From:      Mark Johnston <markj@FreeBSD.org>
To:        Steven Hartland <steven@multiplay.co.uk>
Cc:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r311346 - in head/sys: kern sys vm
Message-ID:  <20170105171321.GA70590@raichu>
In-Reply-To: <3cf413dd-f8d5-4462-9486-0a56adf08b77@freebsd.org>
References:  <201701050144.v051iCso008577@repo.freebsd.org> <3cf413dd-f8d5-4462-9486-0a56adf08b77@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 05, 2017 at 09:16:02AM +0000, Steven Hartland wrote:
> Given the use of the number of CPU's for sizing would this play nice 
> with hot plug CPU's?
> 
>      Regards
>      Steve

Not without some work. I don't think it would be a major obstacle to
adding hot-plug CPU support on at least 64-bit systems though.

> 
> On 05/01/2017 01:44, Mark Johnston wrote:
> > Author: markj
> > Date: Thu Jan  5 01:44:12 2017
> > New Revision: 311346
> > URL: https://svnweb.freebsd.org/changeset/base/311346
> >
> > Log:
> >    Add a small allocator for exec_map entries.
> >    
> >    Upon each execve, we allocate a KVA range for use in copying data to the
> >    new image. Pages must be faulted into the range, and when the range is
> >    freed, the backing pages are freed and their mappings are destroyed. This
> >    is a lot of needless overhead, and the exec_map management becomes a
> >    bottleneck when many CPUs are executing execve concurrently. Moreover, the
> >    number of available ranges is fixed at 16, which is insufficient on large
> >    systems and potentially excessive on 32-bit systems.
> >    
> >    The new allocator reduces overhead by making exec_map allocations
> >    persistent. When a range is freed, pages backing the range are marked clean
> >    and made easy to reclaim. With this change, the exec_map is sized based on
> >    the number of CPUs.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170105171321.GA70590>