Re: PostgreSQL performance on FreeBSD

 > >>> 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.