PostgreSQL performance on FreeBSD
mmacy at nextbsd.org
Fri Jun 3 17:13:22 UTC 2016
> >>> 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.
More information about the freebsd-performance