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>