Re: [Qemu-devel] Dual userfaultfd behavior
Hello, On 03/18/2017 02:27 AM, Mike Kravetz wrote: On 03/15/2017 06:47 AM, Alexey Perevalov wrote: Hi Andrea, thank you for so perfect design description, the main question who will do RFC patches, you or Mike or if you not against I could try. Sorry for not replying sooner, I have been away from e-mail. I have some other projects which require attention before I could start any in depth work on this issue. ok, if nobody started, let me to begin to code that. I already implemented straightforward approach, but it didn't take into account page migration. On 03/14/2017 12:46 AM, Andrea Arcangeli wrote: I think what is needed is an extension to UFFDIO_COPY so that it will not fail if used with lower granularity than the hugetlbfs page size. Then a special feature flag should be set in the uffdio_api.features to tell userland it can use a lower granularity than the hugetlbfs page size. UFFDIO_COPY will still allocate a 1GB page, but it will copy only part of and then map only the copied part with a pte of 4k granularity (or 2MB granularity if the uffdio_copy.dst/len parameters allows for hugepmds). This way if there's a missing fault in the part that is not copied yet, it'll still trigger a page fault and we'll call handle_userfault from hugetlb_no_page, which will trigger a new UFFDIO_COPY and map another fragment of the 1GB page. The same code than should allow us to map a 2MB hugetlbfs page with 4k granularity in UFFDIO_COPY so then userland can choose if to do postcopy live migration on hugetlbfs with 2MB or 4kb granularity (on very slow network 4kb would be preferable for example for the latency). Mapping a 1GB page without a hugepud or mapping a 2MB page without a hugepmd breaks all sort of invariants into the hugetlbfs code, page migration wouldn't be able to cope with it either. Solving the fallout from such breakage is what is required to implement this basically. Agree! I was wondering if it might be easier or more straight forward to split the target vma. You would then create a new vma of the copy page size to be used during the copy. In this way the the mappings and page table entries remain as expected. Of course, you would still want to allocate a huge page of the original target vma size and map that as smaller page sizes are copied. I don't think there is anything that does something similar today. When the copy is done (or aborted) we then create/convert a new vma for the huge page and merge it into the target vma(s). Not sure if that would be any easier. It was just the first thing that popped into my head. -- Best regards, Alexey Perevalov
Re: [Qemu-devel] Dual userfaultfd behavior
On 03/15/2017 06:47 AM, Alexey Perevalov wrote: > Hi Andrea, > > thank you for so perfect design description, > > the main question who will do RFC patches, > you or Mike or if you not against I could try. Sorry for not replying sooner, I have been away from e-mail. I have some other projects which require attention before I could start any in depth work on this issue. > On 03/14/2017 12:46 AM, Andrea Arcangeli wrote: >> I think what is needed is an extension to UFFDIO_COPY so that it will >> not fail if used with lower granularity than the hugetlbfs page >> size. Then a special feature flag should be set in the >> uffdio_api.features to tell userland it can use a lower granularity >> than the hugetlbfs page size. >> >> UFFDIO_COPY will still allocate a 1GB page, but it will copy only part >> of and then map only the copied part with a pte of 4k granularity (or >> 2MB granularity if the uffdio_copy.dst/len parameters allows for >> hugepmds). This way if there's a missing fault in the part that is not >> copied yet, it'll still trigger a page fault and we'll call >> handle_userfault from hugetlb_no_page, which will trigger a new >> UFFDIO_COPY and map another fragment of the 1GB page. >> The same code than should allow us to map a 2MB hugetlbfs page with 4k >> granularity in UFFDIO_COPY so then userland can choose if to do >> postcopy live migration on hugetlbfs with 2MB or 4kb granularity (on >> very slow network 4kb would be preferable for example for the latency). >> >> Mapping a 1GB page without a hugepud or mapping a 2MB page without a >> hugepmd breaks all sort of invariants into the hugetlbfs code, page >> migration wouldn't be able to cope with it either. Solving the fallout >> from such breakage is what is required to implement this basically. Agree! I was wondering if it might be easier or more straight forward to split the target vma. You would then create a new vma of the copy page size to be used during the copy. In this way the the mappings and page table entries remain as expected. Of course, you would still want to allocate a huge page of the original target vma size and map that as smaller page sizes are copied. I don't think there is anything that does something similar today. When the copy is done (or aborted) we then create/convert a new vma for the huge page and merge it into the target vma(s). Not sure if that would be any easier. It was just the first thing that popped into my head. -- Mike Kravetz
Re: [Qemu-devel] Dual userfaultfd behavior
Hi Andrea, thank you for so perfect design description, the main question who will do RFC patches, you or Mike or if you not against I could try. On 03/14/2017 12:46 AM, Andrea Arcangeli wrote: Hello, On Mon, Mar 13, 2017 at 10:53:39AM +, Dr. David Alan Gilbert wrote: * Alexey Perevalov (a.pereva...@samsung.com) wrote: Hi, David, Andrea and Mike Hi Alexey, The problem I want to discuss it's 1G hugepage based VM and post copy live migration. I would like to know your opinion on following approach of avoiding such problem: Once we have mmap'ed area through 1G hugetlbfs, remap physical pages with /dev/mem. It will be 2 types of vmas mapped to the same PFN. Register userfaultfd for newly obtained virtual addresses, it could reduce granularity of pages and reduce downtime per one 1G page. So registering userfaultfd for 2Mb, when the real hugepage was 1G, I think, could help. Current postcopy implementation in QEMU allows to make live migration from 1G based hugepage VM to 2Mb based hugepages VM (sanity checks prevent it). Also I checked, it's possible to remap through /dev/mem and get PFN based vmas, register userfaultfd (with allowance in vma_can_userfault) and finally make UFFDIO_COPY with allowing PFN based vmas in __mcopy_atomic. But there are a lot of drawback of such approach: First of all it's /dev/mem interface. Need to provide full access (kernel w/o CONFIG_STRICT_DEVMEM) and need to disable PAT. The second drawback, maybe I just didn't find possibility to remap hugepages again, but mmap of /dev/mem character driver maps 4Kb pages. I don't know how THP could help here, but madvise with MADV_HUGEPAGE didn't. So 4Kb is not exactly what needed, due to overhead of encapsulation summary downtime is worse than in other cases. It would be great to have interface to obtain new virtual address based on existing PFN, but for hugepages. Yes, and I think as well on some architectures there can be cache problems from mapping the same page in two addresses unless we're careful. I think to do this we'd basically need the kernel to set up something similar to what you're saying, but without the mess of having to go via /dev/mem. Ideally it would all happen magically when I mark /dev/mem is problematic also if the hugetlbfs page is being migrated for example (the virtual2physical mapping that may change and be directed to a different physical page with no notification to userland). a hugetlb page as userfault and start UFFDIO_COPYing in 4kb pages; but I can imagine perhaps some more syscalls needed to tell it to do it. I think what is needed is an extension to UFFDIO_COPY so that it will not fail if used with lower granularity than the hugetlbfs page size. Then a special feature flag should be set in the uffdio_api.features to tell userland it can use a lower granularity than the hugetlbfs page size. UFFDIO_COPY will still allocate a 1GB page, but it will copy only part of and then map only the copied part with a pte of 4k granularity (or 2MB granularity if the uffdio_copy.dst/len parameters allows for hugepmds). This way if there's a missing fault in the part that is not copied yet, it'll still trigger a page fault and we'll call handle_userfault from hugetlb_no_page, which will trigger a new UFFDIO_COPY and map another fragment of the 1GB page. The same code than should allow us to map a 2MB hugetlbfs page with 4k granularity in UFFDIO_COPY so then userland can choose if to do postcopy live migration on hugetlbfs with 2MB or 4kb granularity (on very slow network 4kb would be preferable for example for the latency). Mapping a 1GB page without a hugepud or mapping a 2MB page without a hugepmd breaks all sort of invariants into the hugetlbfs code, page migration wouldn't be able to cope with it either. Solving the fallout from such breakage is what is required to implement this basically. Ideally this could be a UFFDIO_COPY-only feature, simply every other part of hugetlbfs should be able to cope with whatever UFFDIO_COPY has generated in terms of pagetables mapping those hugepages. The only thing that will change from hugetlbfs point of view is that a pte or hugepmd could be mapping a 1GB page, that couldn't be the case before it. Once the entirety of the hugepage has been mapped or when the UFFDIO_UNREGISTER is called on the 1GB range, all those hugepmds and/or ptes should be dropped and the hugepud would then point directly to the 1GB page restoring the current behavior (which is required to get a 1GB large TLB and top performance, i.e. immediately after the live migration completed). This is very different concept than THP that in fact never requires to allocate hugepages. THP nowadays also allows to map a THP page using ptes, instead of hugepmds, just for a different reason (i.e. to allow split_huge_page to fail and be deferred, so get/put_page are simplified, while still guaranteeing that split_huge_page_pmd cannot fail). So we're already doing something like the above with THP but
Re: [Qemu-devel] Dual userfaultfd behavior
Hello, On Mon, Mar 13, 2017 at 10:53:39AM +, Dr. David Alan Gilbert wrote: > * Alexey Perevalov (a.pereva...@samsung.com) wrote: > > Hi, David, Andrea and Mike > > Hi Alexey, > > > The problem I want to discuss it's 1G hugepage based VM and post copy live > > migration. > > > > I would like to know your opinion on following approach of avoiding such > > problem: > > Once we have mmap'ed area through 1G hugetlbfs, remap physical pages > > with /dev/mem. It will be 2 types of vmas mapped to the same PFN. > > Register userfaultfd for newly obtained virtual > > addresses, it could reduce granularity of pages and reduce downtime per > > one 1G page. So registering userfaultfd for 2Mb, when the real hugepage > > was 1G, I think, could help. > > > > Current postcopy implementation in QEMU allows to make live migration > > from 1G based hugepage VM to 2Mb based hugepages VM (sanity checks prevent > > it). > > > > Also I checked, it's possible to remap through /dev/mem and get PFN > > based vmas, register userfaultfd (with allowance in vma_can_userfault) > > and finally make UFFDIO_COPY with allowing PFN based vmas in __mcopy_atomic. > > > > But there are a lot of drawback of such approach: > > First of all it's /dev/mem interface. Need to provide full access > > (kernel w/o CONFIG_STRICT_DEVMEM) and need to disable PAT. > > The second drawback, maybe I just didn't find possibility to remap > > hugepages again, but mmap of /dev/mem character driver maps 4Kb pages. > > I don't know how THP could help here, but madvise with MADV_HUGEPAGE > > didn't. So 4Kb is not exactly what needed, due to overhead of > > encapsulation summary downtime is worse than in other cases. > > It would be great to have interface to obtain new virtual address based > > on existing PFN, but for hugepages. > > Yes, and I think as well on some architectures there can be cache problems > from mapping the same page in two addresses unless we're careful. > > I think to do this we'd basically need the kernel to set up something > similar to what you're saying, but without the mess of having to > go via /dev/mem. Ideally it would all happen magically when I mark /dev/mem is problematic also if the hugetlbfs page is being migrated for example (the virtual2physical mapping that may change and be directed to a different physical page with no notification to userland). > a hugetlb page as userfault and start UFFDIO_COPYing in 4kb pages; > but I can imagine perhaps some more syscalls needed to tell it to do it. I think what is needed is an extension to UFFDIO_COPY so that it will not fail if used with lower granularity than the hugetlbfs page size. Then a special feature flag should be set in the uffdio_api.features to tell userland it can use a lower granularity than the hugetlbfs page size. UFFDIO_COPY will still allocate a 1GB page, but it will copy only part of and then map only the copied part with a pte of 4k granularity (or 2MB granularity if the uffdio_copy.dst/len parameters allows for hugepmds). This way if there's a missing fault in the part that is not copied yet, it'll still trigger a page fault and we'll call handle_userfault from hugetlb_no_page, which will trigger a new UFFDIO_COPY and map another fragment of the 1GB page. The same code than should allow us to map a 2MB hugetlbfs page with 4k granularity in UFFDIO_COPY so then userland can choose if to do postcopy live migration on hugetlbfs with 2MB or 4kb granularity (on very slow network 4kb would be preferable for example for the latency). Mapping a 1GB page without a hugepud or mapping a 2MB page without a hugepmd breaks all sort of invariants into the hugetlbfs code, page migration wouldn't be able to cope with it either. Solving the fallout from such breakage is what is required to implement this basically. Ideally this could be a UFFDIO_COPY-only feature, simply every other part of hugetlbfs should be able to cope with whatever UFFDIO_COPY has generated in terms of pagetables mapping those hugepages. The only thing that will change from hugetlbfs point of view is that a pte or hugepmd could be mapping a 1GB page, that couldn't be the case before it. Once the entirety of the hugepage has been mapped or when the UFFDIO_UNREGISTER is called on the 1GB range, all those hugepmds and/or ptes should be dropped and the hugepud would then point directly to the 1GB page restoring the current behavior (which is required to get a 1GB large TLB and top performance, i.e. immediately after the live migration completed). This is very different concept than THP that in fact never requires to allocate hugepages. THP nowadays also allows to map a THP page using ptes, instead of hugepmds, just for a different reason (i.e. to allow split_huge_page to fail and be deferred, so get/put_page are simplified, while still guaranteeing that split_huge_page_pmd cannot fail). So we're already doing something like the above with THP but we only cover ptes vs hugepmd. The codebase however
Re: [Qemu-devel] Dual userfaultfd behavior
* Alexey Perevalov (a.pereva...@samsung.com) wrote: > Hi, David, Andrea and Mike Hi Alexey, > The problem I want to discuss it's 1G hugepage based VM and post copy live > migration. > > I would like to know your opinion on following approach of avoiding such > problem: > Once we have mmap'ed area through 1G hugetlbfs, remap physical pages > with /dev/mem. It will be 2 types of vmas mapped to the same PFN. > Register userfaultfd for newly obtained virtual > addresses, it could reduce granularity of pages and reduce downtime per > one 1G page. So registering userfaultfd for 2Mb, when the real hugepage > was 1G, I think, could help. > > Current postcopy implementation in QEMU allows to make live migration > from 1G based hugepage VM to 2Mb based hugepages VM (sanity checks prevent > it). > > Also I checked, it's possible to remap through /dev/mem and get PFN > based vmas, register userfaultfd (with allowance in vma_can_userfault) > and finally make UFFDIO_COPY with allowing PFN based vmas in __mcopy_atomic. > > But there are a lot of drawback of such approach: > First of all it's /dev/mem interface. Need to provide full access > (kernel w/o CONFIG_STRICT_DEVMEM) and need to disable PAT. > The second drawback, maybe I just didn't find possibility to remap > hugepages again, but mmap of /dev/mem character driver maps 4Kb pages. > I don't know how THP could help here, but madvise with MADV_HUGEPAGE > didn't. So 4Kb is not exactly what needed, due to overhead of > encapsulation summary downtime is worse than in other cases. > It would be great to have interface to obtain new virtual address based > on existing PFN, but for hugepages. Yes, and I think as well on some architectures there can be cache problems from mapping the same page in two addresses unless we're careful. I think to do this we'd basically need the kernel to set up something similar to what you're saying, but without the mess of having to go via /dev/mem. Ideally it would all happen magically when I mark a hugetlb page as userfault and start UFFDIO_COPYing in 4kb pages; but I can imagine perhaps some more syscalls needed to tell it to do it. I've no idea how hard that is to do though. Dave > Honestly, I can't find another use case for this feature. > > > -- > > BR > Alexey -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
