From owner-freebsd-current@freebsd.org Fri Jun 3 17:13:21 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D9D86B697BA; Fri, 3 Jun 2016 17:13:21 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C5DE91F14; Fri, 3 Jun 2016 17:13:21 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1464973993043178.94664369864552; Fri, 3 Jun 2016 10:13:13 -0700 (PDT) Date: Fri, 03 Jun 2016 10:13:12 -0700 From: Matthew Macy To: "Alan Somers" Cc: "Alan Cox" , "John Baldwin" , "" , "Konstantin Belousov" , "Adrian Chadd" , "freebsd-current" , "" , "current@freebsd.org" Message-ID: <15517412419.c1e94b0289020.2514233510095214876@nextbsd.org> In-Reply-To: References: <20140627125613.GT93733@kib.kiev.ua> <201408121409.40653.jhb@freebsd.org> <201408141147.45698.jhb@freebsd.org> <53ECFDC8.1070200@rice.edu> Subject: Re: PostgreSQL performance on FreeBSD MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 17:13:22 -0000 > >>> A couple small steps have been taken toward eliminating the need for this > >>> hack: the addition of the "page size index" field to struct vm_page and the > >>> addition of a similarly named parameter to pmap_enter(). However, at the > >>> moment, the only tangible effect is in the automatic prefaulting by > >>> mmap(2). Instead of establishing 96 4KB page mappings, the automatic > >>> prefaulting establishes 96 page mappings whose size is determined by the > >>> size of the physical pages that it finds in the vm object. So, the > >>> prefaulting overhead remains constant, but the coverage provided by the > >>> automatic prefaulting will vary with the underlying page size. > >> Yes, I think what we might actually want is what I mentioned in person at > >> BSDCan: some sort of flag to mmap() that malloc() could use to assume that any > >> reservations are fully used when they are reserved. This would avoid the need > >> to wait for all pages to be dirtied before promotion provides a superpage > >> mapping and would avoid demotions while still allowing the kernel to gracefully > >> fall back to regular pages if a reservation can't be made. > >> > > > > I agree. > > I notice that, with the exception of the VM_PHYSSEG_MAX change, these > patches never made it into head or ports. Are they unsuitable for low > core-count machines, or is there some other reason not to commit them? > If not, what would it take to get these into 11.0 or 11.1 ? > I think the two big issues are: a) there's a lot more work that needs to be done b) Adrian has had a lot of other things on his plate in the meantime. Adrian is hoping to get back to it post 11.0-RELEASE.