search for: thps

...inflate and deflate. > >> Opening this flag can bring two benefits: > >> 1. Report continuous pages will increase memory report size of each time > >> call tell_host. Then it will increase the speed of balloon inflate and > >> deflate. > >> 2. Host THPs will be splitted when qemu release the page of balloon inflate. > >> Inflate balloon with continuous pages will let QEMU release the pages > >> of same THPs. That will help decrease the splitted THPs number in > >> the host. > >> Following is an example...

...g, balloon tries to use continuous pages to inflate and deflate. > Opening this flag can bring two benefits: > 1. Report continuous pages will increase memory report size of each time > call tell_host. Then it will increase the speed of balloon inflate and > deflate. > 2. Host THPs will be splitted when qemu release the page of balloon inflate. > Inflate balloon with continuous pages will let QEMU release the pages > of same THPs. That will help decrease the splitted THPs number in > the host. > Following is an example in a VM with 1G memory 1CPU. Th...

...t with a > 2MB mapping. > Sure, the I/O will work OK, but is it safe? Copy on write isn't an issue? splitting a PMD in one process due to mprotect of a shared page will cause other process' page tables to be split the same way? Recall that these are system memory pages that could be THPs, shmem, hugetlbfs, mmap shared file pages, etc.

...inly want to fallback to allocating pages in a smaller granularity once you run out of bigger allocations. Sacrifice performance for memory inflation, which has always been the case and which is what people expect to happen. (e.g., to shrink the page cache properly) 2. You are essentially stealing THPs in the guest. So the fastest mapping (THP in guest and host) is gone. The guest won't be able to make use of THP where it previously was able to. I can imagine this implies a performance degradation for some workloads. This needs a proper performance evaluation. 3. The pages you allocate are n...

...inly want to fallback to allocating pages in a smaller granularity once you run out of bigger allocations. Sacrifice performance for memory inflation, which has always been the case and which is what people expect to happen. (e.g., to shrink the page cache properly) 2. You are essentially stealing THPs in the guest. So the fastest mapping (THP in guest and host) is gone. The guest won't be able to make use of THP where it previously was able to. I can imagine this implies a performance degradation for some workloads. This needs a proper performance evaluation. 3. The pages you allocate are n...

...te: This description needs an overhaul, it's hard to parse. > If the guest kernel has many fragmentation pages, use virtio_balloon > will split THP of QEMU when it calls MADV_DONTNEED madvise to release > the balloon pages. This is very unclear and confusing. You will *always* split THPs when inflating 4k pages and there are THPs around. This is completely independent of any fragmentation in the guest. The thing you are trying to achieve here is trying to *minimize* the number of split THPs in the hypervisor *after* the balloon was completely inflated. > Set option cont-pages t...

...useful to have a filter saying "migrate system memory not already in NUMA zone X" if the MIGRATE_VMA_SELECT_SYSTEM flag is set. Also, in support of the flags field, I'm looking at THP migration and I can picture defining some request flags like hmm_range_fault() to say "migrate THPs if they exist, otherwise split THPs". A default_flags MIGRATE_PFN_REQ_FAULT would be useful if the source page is swapped out. Currently, migrate_vma_setup() just skips these pages without any indication to the caller why the page isn't being migrated or if retrying is worth attempting.

On 19 Jun 2020, at 17:56, Ralph Campbell wrote: > Transparent huge page allocation policy is controlled by several sysfs > variables. Rather than expose these to each device driver that needs to > allocate THPs, provide a helper function. > > Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> > --- > include/linux/gfp.h | 10 ++++++++++ > mm/huge_memory.c | 16 ++++++++++++++++ > 2 files changed, 26 insertions(+) > > diff --git a/include/linux/gfp.h b/include/linux/g...

On Mon, Jul 20, 2020 at 01:49:09PM -0700, Ralph Campbell wrote: > > On 7/20/20 12:59 PM, Jason Gunthorpe wrote: > > On Mon, Jul 20, 2020 at 12:54:53PM -0700, Ralph Campbell wrote: > > > > > diff --git a/include/linux/migrate.h b/include/linux/migrate.h > > > > > index 3e546cbf03dd..620f2235d7d4 100644 > > > > > +++ b/include/linux/migrate.h

...reproduce this quite easily by filling pagecache (i.e. dd-ing a single large file to /dev/null) before running the application. The problem seems to be that the kernel is not freeing (or has some trouble freeing) the non-dirty and (presumably immediately) reclaimable pagecache in order to allocate THPs for the application. This behaviour is also observable on regular bare-metal, but the slowdown is only 10-20% there - the nested paging of the guest really makes THP allocation important there (1). Both current CentOS and Ubuntu guests have the issue. Some more environmental context: the VMs are t...

...re you saying that if you call this function on an address range of a process which has done COW of a single page in the middle of a THP, you want to return with this flag clear, but if the THP is still intact, you want to set this flag? > Recall that these are system memory pages that could be THPs, shmem, hugetlbfs, > mmap shared file pages, etc.

Transparent huge page allocation policy is controlled by several sysfs variables. Rather than expose these to each device driver that needs to allocate THPs, provide a helper function. Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> --- include/linux/gfp.h | 10 ++++++++++ mm/huge_memory.c | 16 ++++++++++++++++ 2 files changed, 26 insertions(+) diff --git a/include/linux/gfp.h b/include/linux/gfp.h index 67a0774e080b..1c7d968a27d3...

Transparent huge page allocation policy is controlled by several sysfs variables. Rather than expose these to each device driver that needs to allocate THPs, provide a helper function. Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> --- include/linux/gfp.h | 10 ++++++++++ mm/huge_memory.c | 14 ++++++++++++++ 2 files changed, 24 insertions(+) diff --git a/include/linux/gfp.h b/include/linux/gfp.h index c603237e006c..242398c4b556 10...

On Thu, Mar 12, 2020 at 09:37:32AM +0100, David Hildenbrand wrote: > 2. You are essentially stealing THPs in the guest. So the fastest > mapping (THP in guest and host) is gone. The guest won't be able to make > use of THP where it previously was able to. I can imagine this implies a > performance degradation for some workloads. This needs a proper > performance evaluation. I think the...

...e easily by > filling pagecache (i.e. dd-ing a single large file to /dev/null) before > running the application. The problem seems to be that the kernel is not > freeing (or has some trouble freeing) the non-dirty and (presumably > immediately) reclaimable pagecache in order to allocate THPs for the > application. > > This behaviour is also observable on regular bare-metal, but the slowdown > is only 10-20% there - the nested paging of the guest really makes THP > allocation important there (1). Both current CentOS and Ubuntu guests have > the issue. Some more enviro...

...: > >>>>>>>>>>> On 12.03.20 09:47, Michael S. Tsirkin wrote: > >>>>>>>>>>> On Thu, Mar 12, 2020 at 09:37:32AM +0100, David Hildenbrand wrote: > >>>>>>>>>>>> 2. You are essentially stealing THPs in the guest. So the fastest > >>>>>>>>>>>> mapping (THP in guest and host) is gone. The guest won't be able to make > >>>>>>>>>>>> use of THP where it previously was able to. I can imagine this implies a > >&gt...

...;>>>>>>>>>>> On 12.03.20 09:47, Michael S. Tsirkin wrote: >>>>>>>>>>>>> On Thu, Mar 12, 2020 at 09:37:32AM +0100, David Hildenbrand wrote: >>>>>>>>>>>>>> 2. You are essentially stealing THPs in the guest. So the fastest >>>>>>>>>>>>>> mapping (THP in guest and host) is gone. The guest won't be able to make >>>>>>>>>>>>>> use of THP where it previously was able to. I can imagine this implies a >&g...

...:51:25AM +0100, David Hildenbrand wrote: >>>>>>>>> On 12.03.20 09:47, Michael S. Tsirkin wrote: >>>>>>>>> On Thu, Mar 12, 2020 at 09:37:32AM +0100, David Hildenbrand wrote: >>>>>>>>>> 2. You are essentially stealing THPs in the guest. So the fastest >>>>>>>>>> mapping (THP in guest and host) is gone. The guest won't be able to make >>>>>>>>>> use of THP where it previously was able to. I can imagine this implies a >>>>>>>>>&g...

Support transparent huge page migration to ZONE_DEVICE private memory. A new selection flag (MIGRATE_VMA_SELECT_COMPOUND) is added to request THP migration. Otherwise, THPs are split when filling in the source PFN array. A new flag (MIGRATE_PFN_COMPOUND) is added to the source PFN array to indicate a huge page can be migrated. If the device driver can allocate a huge page, it sets the MIGRATE_PFN_COMPOUND flag in the destination PFN array. migrate_vma_pages() will fal...

This series adds support for transparent huge page migration to migrate_vma_*() and adds nouveau SVM and HMM selftests as consumers. Earlier versions were posted previously [1] and [2]. The patches apply cleanly to the linux-mm 5.10.0-rc2 tree. There are a lot of other THP patches being posted. I don't think there are any semantic conflicts but there may be some merge conflicts depending on