On Tue, May 30, 2017 at 12:39:30PM +0200, Michal Hocko wrote: > On Tue 30-05-17 13:19:22, Mike Rapoport wrote: > > > > But then we'll have to populate these regions with > > > > UFFDIO_COPY which adds quite an overhead. > > > > > > How big is the performance impact? > > > > I don't have the numbers handy, but for each post-copy range it means that > > instead of memcpy() we will use ioctl(UFFDIO_COPY). > > It would be good to measure that though. I will, but I won't expect huge difference here. Anyway, memcpy() will touch still unpopulated pages, so we'll anyway enter/exit kernel. > You are proposing a new user > API and the THP api is quite convoluted already so there better be a > very good reason to add a new API. So far I can only see that it would > be more convinient to add another madvise command and that is rather > insufficient justification IMHO. Well, the most convenient for my use case would be simply disable THP before restore and re-enable it afterwards. And the need to use ioctl(UFFDIO_COPY) is not that less convenient that the proposed madvise command. I've proposed the new madvise command because I firmly believe it is missing. All madvise() commands that set some flag in vma->vm_flags have the counter-command that resets that flag. Except for THP. The THP-related flags can define three states for a VMA, pretty much like VM_SEQ_READ and VM_RAND_READ. And it requires three madvise commands to allow setting any of the desired states, just like with MADV_RANDOM, MADV_SEQUENTIAL and MADV_NORMAL. > Also do you expect somebody else would use new madvise? What would be the > usecase? I can think of an application that wants to keep 4K pages to save physical memory for certain phase, e.g. until these pages are populated with very few data. After the memory usage increases, the application may wish to stop preventing khugepged from merging these pages, but it does not have strong inclination to force use of huge pages. > -- > Michal Hocko > SUSE Labs -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
