On Mon, Jan 14, 2019 at 10:54:45AM -0800, Mike Kravetz wrote: > On 1/14/19 7:35 AM, Steven Sistare wrote: > > On 1/11/2019 6:28 PM, Mike Kravetz wrote: > >> On 1/11/19 1:55 PM, Kirill A. Shutemov wrote: > >>> On Fri, Jan 11, 2019 at 08:10:03PM +0000, Mike Kravetz wrote: > >>>> At LPC last year, Boaz Harrosh asked why he had to 'jump through hoops' > >>>> to get an address returned by mmap() suitably aligned for THP. It seems > >>>> that if mmap is asking for a mapping length greater than huge page > >>>> size, it should align the returned address to huge page size. > > > > A better heuristic would be to return an aligned address if the length > > is a multiple of the huge page size. The gap (if any) between the end of > > the previous VMA and the start of this VMA would be filled by subsequent > > smaller mmap requests. The new behavior would need to become part of the > > mmap interface definition so apps can rely on it and omit their hoop-jumping > > code. > > Yes, the heuristic really should be 'length is a multiple of the huge page > size'. As you mention, this would still leave gaps. I need to look closer > but this may not be any worse than the trick of mapping an area with rounded > up length and then unmapping pages at the beginning. The question why is it any better. Virtual address space is generally cheap, additional VMA maybe more signficiant due to find_vma() overhead. And you don't *need* to unmap anything. Just use alinged pointer. > > When I sent this out, the thought in the back of my mind was that this doesn't > really matter unless there is some type of alignment guarantee. Otherwise, > user space code needs continue employing their code to check/force alignment. > Making matters somewhat worse is that I do not believe there is C interface to > query huge page size. I thought there was discussion about adding one, but I > can not find it. We have posix_memalign(3). -- Kirill A. Shutemov
