Date: Fri, 03 Jun 2016 10:13:12 -0700 From: Matthew Macy <mmacy@nextbsd.org> To: "Alan Somers" <asomers@freebsd.org> Cc: "Alan Cox" <alc@rice.edu>, "John Baldwin" <jhb@freebsd.org>, "<alc@freebsd.org>" <alc@freebsd.org>, "Konstantin Belousov" <kostikbel@gmail.com>, "Adrian Chadd" <adrian@freebsd.org>, "freebsd-current" <freebsd-current@freebsd.org>, "<performance@freebsd.org>" <performance@freebsd.org>, "current@freebsd.org" <current@freebsd.org> Subject: Re: PostgreSQL performance on FreeBSD Message-ID: <15517412419.c1e94b0289020.2514233510095214876@nextbsd.org> In-Reply-To: <CAOtMX2iH7=AAvHWg7xw=u5nyO6ANF1J3uVMKPsf%2BV=PYBEumvA@mail.gmail.com> References: <20140627125613.GT93733@kib.kiev.ua> <201408121409.40653.jhb@freebsd.org> <CAJUyCcMAw-etXh3gByLE_xpLOkO=LZihUVVfzgAtSb809QcPWA@mail.gmail.com> <201408141147.45698.jhb@freebsd.org> <53ECFDC8.1070200@rice.edu> <CAOtMX2iH7=AAvHWg7xw=u5nyO6ANF1J3uVMKPsf%2BV=PYBEumvA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> >>> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15517412419.c1e94b0289020.2514233510095214876>