Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Thu, Jun 01, 2017 at 03:45:22PM +0200, Andrea Arcangeli wrote: > On Thu, Jun 01, 2017 at 10:09:09AM +0200, Michal Hocko wrote: > > That is a bit surprising. I didn't think that the userfault syscall > > (ioctl) can be faster than a regular #PF but considering that > > __mcopy_atomic bypasses

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Thu, Jun 01, 2017 at 03:45:22PM +0200, Andrea Arcangeli wrote: > On Thu, Jun 01, 2017 at 10:09:09AM +0200, Michal Hocko wrote: > > That is a bit surprising. I didn't think that the userfault syscall > > (ioctl) can be faster than a regular #PF but considering that > > __mcopy_atomic bypasses

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Thu, Jun 01, 2017 at 10:09:09AM +0200, Michal Hocko wrote: > That is a bit surprising. I didn't think that the userfault syscall > (ioctl) can be faster than a regular #PF but considering that > __mcopy_atomic bypasses the page fault path and it can be optimized for > the anon case suggests

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Thu, Jun 01, 2017 at 10:09:09AM +0200, Michal Hocko wrote: > That is a bit surprising. I didn't think that the userfault syscall > (ioctl) can be faster than a regular #PF but considering that > __mcopy_atomic bypasses the page fault path and it can be optimized for > the anon case suggests

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Thu 01-06-17 14:00:48, Mike Rapoport wrote: > On Wed, May 31, 2017 at 10:24:14AM +0200, Michal Hocko wrote: > > On Wed 31-05-17 08:30:08, Vlastimil Babka wrote: > > > On 05/30/2017 06:06 PM, Andrea Arcangeli wrote: > > > > > > > > I'm not sure if it should be considered a bug, the prctl is

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Thu 01-06-17 14:00:48, Mike Rapoport wrote: > On Wed, May 31, 2017 at 10:24:14AM +0200, Michal Hocko wrote: > > On Wed 31-05-17 08:30:08, Vlastimil Babka wrote: > > > On 05/30/2017 06:06 PM, Andrea Arcangeli wrote: > > > > > > > > I'm not sure if it should be considered a bug, the prctl is

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed, May 31, 2017 at 10:24:14AM +0200, Michal Hocko wrote: > On Wed 31-05-17 08:30:08, Vlastimil Babka wrote: > > On 05/30/2017 06:06 PM, Andrea Arcangeli wrote: > > > > > > I'm not sure if it should be considered a bug, the prctl is intended > > > to use normally by wrappers so it looks

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed, May 31, 2017 at 10:24:14AM +0200, Michal Hocko wrote: > On Wed 31-05-17 08:30:08, Vlastimil Babka wrote: > > On 05/30/2017 06:06 PM, Andrea Arcangeli wrote: > > > > > > I'm not sure if it should be considered a bug, the prctl is intended > > > to use normally by wrappers so it looks

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Thu, Jun 01, 2017 at 10:09:09AM +0200, Michal Hocko wrote: > On Thu 01-06-17 09:53:02, Mike Rapoport wrote: > > On Tue, May 30, 2017 at 04:39:41PM +0200, Michal Hocko wrote: > > > On Tue 30-05-17 16:04:56, Andrea Arcangeli wrote: > > > > > > > > UFFDIO_COPY while not being a major slowdown for

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Thu, Jun 01, 2017 at 10:09:09AM +0200, Michal Hocko wrote: > On Thu 01-06-17 09:53:02, Mike Rapoport wrote: > > On Tue, May 30, 2017 at 04:39:41PM +0200, Michal Hocko wrote: > > > On Tue 30-05-17 16:04:56, Andrea Arcangeli wrote: > > > > > > > > UFFDIO_COPY while not being a major slowdown for

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Thu 01-06-17 09:53:02, Mike Rapoport wrote: > On Tue, May 30, 2017 at 04:39:41PM +0200, Michal Hocko wrote: > > On Tue 30-05-17 16:04:56, Andrea Arcangeli wrote: > > > > > > UFFDIO_COPY while not being a major slowdown for sure, it's likely > > > measurable at the microbenchmark level because

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Thu 01-06-17 09:53:02, Mike Rapoport wrote: > On Tue, May 30, 2017 at 04:39:41PM +0200, Michal Hocko wrote: > > On Tue 30-05-17 16:04:56, Andrea Arcangeli wrote: > > > > > > UFFDIO_COPY while not being a major slowdown for sure, it's likely > > > measurable at the microbenchmark level because

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed, May 31, 2017 at 04:18:09PM +0200, Andrea Arcangeli wrote: > On Wed, May 31, 2017 at 03:39:22PM +0300, Mike Rapoport wrote: > > For the CRIU usecase, disabling THP for a while and re-enabling it > > back will do the trick, provided VMAs flags are not affected, like > > in the patch you've

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed, May 31, 2017 at 04:18:09PM +0200, Andrea Arcangeli wrote: > On Wed, May 31, 2017 at 03:39:22PM +0300, Mike Rapoport wrote: > > For the CRIU usecase, disabling THP for a while and re-enabling it > > back will do the trick, provided VMAs flags are not affected, like > > in the patch you've

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Tue, May 30, 2017 at 04:39:41PM +0200, Michal Hocko wrote: > On Tue 30-05-17 16:04:56, Andrea Arcangeli wrote: > > > > UFFDIO_COPY while not being a major slowdown for sure, it's likely > > measurable at the microbenchmark level because it would add a > > enter/exit kernel to every 4k memcpy.

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Tue, May 30, 2017 at 04:39:41PM +0200, Michal Hocko wrote: > On Tue 30-05-17 16:04:56, Andrea Arcangeli wrote: > > > > UFFDIO_COPY while not being a major slowdown for sure, it's likely > > measurable at the microbenchmark level because it would add a > > enter/exit kernel to every 4k memcpy.

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed, May 31, 2017 at 04:32:17PM +0200, Michal Hocko wrote: > I would assume such a patch would be backported to stable trees because > to me it sounds like the current semantic is simply broken and needs > fixing anyway but it shouldn't be much different from any other bugs. So the program

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed, May 31, 2017 at 04:32:17PM +0200, Michal Hocko wrote: > I would assume such a patch would be backported to stable trees because > to me it sounds like the current semantic is simply broken and needs > fixing anyway but it shouldn't be much different from any other bugs. So the program

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed 31-05-17 16:18:09, Andrea Arcangeli wrote: > On Wed, May 31, 2017 at 03:39:22PM +0300, Mike Rapoport wrote: > > For the CRIU usecase, disabling THP for a while and re-enabling it > > back will do the trick, provided VMAs flags are not affected, like > > in the patch you've sent. Moreover,

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed 31-05-17 16:18:09, Andrea Arcangeli wrote: > On Wed, May 31, 2017 at 03:39:22PM +0300, Mike Rapoport wrote: > > For the CRIU usecase, disabling THP for a while and re-enabling it > > back will do the trick, provided VMAs flags are not affected, like > > in the patch you've sent. Moreover,

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed 31-05-17 15:39:22, Mike Rapoprt wrote: > > > On May 31, 2017 3:08:22 PM GMT+03:00, Michal Hocko wrote: [...] > > From what Mike said a global disable THP for the whole process > >while the post-copy is in progress is a better solution anyway. > > For the CRIU usecase,

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed 31-05-17 15:39:22, Mike Rapoprt wrote: > > > On May 31, 2017 3:08:22 PM GMT+03:00, Michal Hocko wrote: [...] > > From what Mike said a global disable THP for the whole process > >while the post-copy is in progress is a better solution anyway. > > For the CRIU usecase, disabling THP for

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed, May 31, 2017 at 03:39:22PM +0300, Mike Rapoport wrote: > For the CRIU usecase, disabling THP for a while and re-enabling it > back will do the trick, provided VMAs flags are not affected, like > in the patch you've sent. Moreover, we may even get away with Are you going to check uname -r

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed, May 31, 2017 at 03:39:22PM +0300, Mike Rapoport wrote: > For the CRIU usecase, disabling THP for a while and re-enabling it > back will do the trick, provided VMAs flags are not affected, like > in the patch you've sent. Moreover, we may even get away with Are you going to check uname -r

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On May 31, 2017 3:08:22 PM GMT+03:00, Michal Hocko wrote: >On Tue 30-05-17 17:43:26, Andrea Arcangeli wrote: >> On Tue, May 30, 2017 at 04:39:41PM +0200, Michal Hocko wrote: >> > I sysctl for the mapcount can be increased, right? I also assume >that >> > those vmas will get

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On May 31, 2017 3:08:22 PM GMT+03:00, Michal Hocko wrote: >On Tue 30-05-17 17:43:26, Andrea Arcangeli wrote: >> On Tue, May 30, 2017 at 04:39:41PM +0200, Michal Hocko wrote: >> > I sysctl for the mapcount can be increased, right? I also assume >that >> > those vmas will get merged after the

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On May 31, 2017 3:05:56 PM GMT+03:00, Michal Hocko wrote: >On Wed 31-05-17 12:08:45, Mike Rapoport wrote: >> On Tue, May 30, 2017 at 12:39:30PM +0200, Michal Hocko wrote: >[...] >> > Also do you expect somebody else would use new madvise? What would >be the >> > usecase? >>

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On May 31, 2017 3:05:56 PM GMT+03:00, Michal Hocko wrote: >On Wed 31-05-17 12:08:45, Mike Rapoport wrote: >> On Tue, May 30, 2017 at 12:39:30PM +0200, Michal Hocko wrote: >[...] >> > Also do you expect somebody else would use new madvise? What would >be the >> > usecase? >> >> I can think of

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Tue 30-05-17 17:43:26, Andrea Arcangeli wrote: > On Tue, May 30, 2017 at 04:39:41PM +0200, Michal Hocko wrote: > > I sysctl for the mapcount can be increased, right? I also assume that > > those vmas will get merged after the post copy is done. > > Assuming you enlarge the sysctl to the worst

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Tue 30-05-17 17:43:26, Andrea Arcangeli wrote: > On Tue, May 30, 2017 at 04:39:41PM +0200, Michal Hocko wrote: > > I sysctl for the mapcount can be increased, right? I also assume that > > those vmas will get merged after the post copy is done. > > Assuming you enlarge the sysctl to the worst

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed 31-05-17 12:08:45, Mike Rapoport wrote: > On Tue, May 30, 2017 at 12:39:30PM +0200, Michal Hocko wrote: [...] > > 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

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed 31-05-17 12:08:45, Mike Rapoport wrote: > On Tue, May 30, 2017 at 12:39:30PM +0200, Michal Hocko wrote: [...] > > 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

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed 31-05-17 12:27:00, Mike Rapoport wrote: > On Wed, May 31, 2017 at 10:24:14AM +0200, Michal Hocko wrote: > > On Wed 31-05-17 08:30:08, Vlastimil Babka wrote: > > > On 05/30/2017 06:06 PM, Andrea Arcangeli wrote: > > > > > > > > I'm not sure if it should be considered a bug, the prctl is

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed 31-05-17 12:27:00, Mike Rapoport wrote: > On Wed, May 31, 2017 at 10:24:14AM +0200, Michal Hocko wrote: > > On Wed 31-05-17 08:30:08, Vlastimil Babka wrote: > > > On 05/30/2017 06:06 PM, Andrea Arcangeli wrote: > > > > > > > > I'm not sure if it should be considered a bug, the prctl is

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed 31-05-17 10:24:14, Michal Hocko wrote: [...] JFTR we also need to update MMF_INIT_MASK as well. +#define MMF_INIT_MASK (MMF_DUMPABLE_MASK | MMF_DUMP_FILTER_MASK | MMF_DISABLE_THP) > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h > index a3762d49ba39..9da053ced864

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed 31-05-17 10:24:14, Michal Hocko wrote: [...] JFTR we also need to update MMF_INIT_MASK as well. +#define MMF_INIT_MASK (MMF_DUMPABLE_MASK | MMF_DUMP_FILTER_MASK | MMF_DISABLE_THP) > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h > index a3762d49ba39..9da053ced864

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed, May 31, 2017 at 10:24:14AM +0200, Michal Hocko wrote: > On Wed 31-05-17 08:30:08, Vlastimil Babka wrote: > > On 05/30/2017 06:06 PM, Andrea Arcangeli wrote: > > > > > > I'm not sure if it should be considered a bug, the prctl is intended > > > to use normally by wrappers so it looks

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed, May 31, 2017 at 10:24:14AM +0200, Michal Hocko wrote: > On Wed 31-05-17 08:30:08, Vlastimil Babka wrote: > > On 05/30/2017 06:06 PM, Andrea Arcangeli wrote: > > > > > > I'm not sure if it should be considered a bug, the prctl is intended > > > to use normally by wrappers so it looks

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

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

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

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

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed 31-05-17 08:30:08, Vlastimil Babka wrote: > On 05/30/2017 06:06 PM, Andrea Arcangeli wrote: > > > > I'm not sure if it should be considered a bug, the prctl is intended > > to use normally by wrappers so it looks optimal as implemented this > > way: affecting future vmas only, which will

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed 31-05-17 08:30:08, Vlastimil Babka wrote: > On 05/30/2017 06:06 PM, Andrea Arcangeli wrote: > > > > I'm not sure if it should be considered a bug, the prctl is intended > > to use normally by wrappers so it looks optimal as implemented this > > way: affecting future vmas only, which will

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On 05/30/2017 06:06 PM, Andrea Arcangeli wrote: > > I'm not sure if it should be considered a bug, the prctl is intended > to use normally by wrappers so it looks optimal as implemented this > way: affecting future vmas only, which will all be created after > execve executed by the wrapper. > >

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On 05/30/2017 06:06 PM, Andrea Arcangeli wrote: > > I'm not sure if it should be considered a bug, the prctl is intended > to use normally by wrappers so it looks optimal as implemented this > way: affecting future vmas only, which will all be created after > execve executed by the wrapper. > >

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Tue, May 30, 2017 at 04:56:33PM +0200, Michal Hocko wrote: > On Tue 30-05-17 16:39:41, Michal Hocko wrote: > > On Tue 30-05-17 16:04:56, Andrea Arcangeli wrote: > [...] > > > About the proposed madvise, it just clear bits, but it doesn't change > > > at all how those bits are computed in THP

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Tue, May 30, 2017 at 04:56:33PM +0200, Michal Hocko wrote: > On Tue 30-05-17 16:39:41, Michal Hocko wrote: > > On Tue 30-05-17 16:04:56, Andrea Arcangeli wrote: > [...] > > > About the proposed madvise, it just clear bits, but it doesn't change > > > at all how those bits are computed in THP

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Tue, May 30, 2017 at 04:39:41PM +0200, Michal Hocko wrote: > I sysctl for the mapcount can be increased, right? I also assume that > those vmas will get merged after the post copy is done. Assuming you enlarge the sysctl to the worst possible case, with 64bit address space you can have

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Tue, May 30, 2017 at 04:39:41PM +0200, Michal Hocko wrote: > I sysctl for the mapcount can be increased, right? I also assume that > those vmas will get merged after the post copy is done. Assuming you enlarge the sysctl to the worst possible case, with 64bit address space you can have

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Tue 30-05-17 16:39:41, Michal Hocko wrote: > On Tue 30-05-17 16:04:56, Andrea Arcangeli wrote: [...] > > About the proposed madvise, it just clear bits, but it doesn't change > > at all how those bits are computed in THP code. So I don't see it as > > convoluted. > > But we already have

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Tue 30-05-17 16:39:41, Michal Hocko wrote: > On Tue 30-05-17 16:04:56, Andrea Arcangeli wrote: [...] > > About the proposed madvise, it just clear bits, but it doesn't change > > at all how those bits are computed in THP code. So I don't see it as > > convoluted. > > But we already have

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Tue 30-05-17 16:04:56, Andrea Arcangeli wrote: > On Tue, May 30, 2017 at 12:39:30PM +0200, Michal Hocko wrote: > > On Tue 30-05-17 13:19:22, Mike Rapoport wrote: > > > On Tue, May 30, 2017 at 09:44:08AM +0200, Michal Hocko wrote: > > > > On Wed 24-05-17 17:27:36, Mike Rapoport wrote: > > > > >

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Tue 30-05-17 16:04:56, Andrea Arcangeli wrote: > On Tue, May 30, 2017 at 12:39:30PM +0200, Michal Hocko wrote: > > On Tue 30-05-17 13:19:22, Mike Rapoport wrote: > > > On Tue, May 30, 2017 at 09:44:08AM +0200, Michal Hocko wrote: > > > > On Wed 24-05-17 17:27:36, Mike Rapoport wrote: > > > > >

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Tue, May 30, 2017 at 12:39:30PM +0200, Michal Hocko wrote: > On Tue 30-05-17 13:19:22, Mike Rapoport wrote: > > On Tue, May 30, 2017 at 09:44:08AM +0200, Michal Hocko wrote: > > > On Wed 24-05-17 17:27:36, Mike Rapoport wrote: > > > > On Wed, May 24, 2017 at 01:18:00PM +0200, Michal Hocko

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Tue, May 30, 2017 at 12:39:30PM +0200, Michal Hocko wrote: > On Tue 30-05-17 13:19:22, Mike Rapoport wrote: > > On Tue, May 30, 2017 at 09:44:08AM +0200, Michal Hocko wrote: > > > On Wed 24-05-17 17:27:36, Mike Rapoport wrote: > > > > On Wed, May 24, 2017 at 01:18:00PM +0200, Michal Hocko

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Tue 30-05-17 13:19:22, Mike Rapoport wrote: > On Tue, May 30, 2017 at 09:44:08AM +0200, Michal Hocko wrote: > > On Wed 24-05-17 17:27:36, Mike Rapoport wrote: > > > On Wed, May 24, 2017 at 01:18:00PM +0200, Michal Hocko wrote: > > [...] > > > > Why cannot khugepaged simply skip over all VMAs

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Tue 30-05-17 13:19:22, Mike Rapoport wrote: > On Tue, May 30, 2017 at 09:44:08AM +0200, Michal Hocko wrote: > > On Wed 24-05-17 17:27:36, Mike Rapoport wrote: > > > On Wed, May 24, 2017 at 01:18:00PM +0200, Michal Hocko wrote: > > [...] > > > > Why cannot khugepaged simply skip over all VMAs

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Tue, May 30, 2017 at 09:44:08AM +0200, Michal Hocko wrote: > On Wed 24-05-17 17:27:36, Mike Rapoport wrote: > > On Wed, May 24, 2017 at 01:18:00PM +0200, Michal Hocko wrote: > [...] > > > Why cannot khugepaged simply skip over all VMAs which have userfault > > > regions registered? This would

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Tue, May 30, 2017 at 09:44:08AM +0200, Michal Hocko wrote: > On Wed 24-05-17 17:27:36, Mike Rapoport wrote: > > On Wed, May 24, 2017 at 01:18:00PM +0200, Michal Hocko wrote: > [...] > > > Why cannot khugepaged simply skip over all VMAs which have userfault > > > regions registered? This would

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed 24-05-17 17:27:36, Mike Rapoport wrote: > On Wed, May 24, 2017 at 01:18:00PM +0200, Michal Hocko wrote: [...] > > Why cannot khugepaged simply skip over all VMAs which have userfault > > regions registered? This would sound like a less error prone approach to > > me. > > khugepaged does

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed 24-05-17 17:27:36, Mike Rapoport wrote: > On Wed, May 24, 2017 at 01:18:00PM +0200, Michal Hocko wrote: [...] > > Why cannot khugepaged simply skip over all VMAs which have userfault > > regions registered? This would sound like a less error prone approach to > > me. > > khugepaged does

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

Hello, On Wed, May 24, 2017 at 05:27:36PM +0300, Mike Rapoport wrote: > khugepaged does skip over VMAs which have userfault. We could register the > regions with userfault before populating them to avoid collapses in the > transition period. But then we'll have to populate these regions with >

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

Hello, On Wed, May 24, 2017 at 05:27:36PM +0300, Mike Rapoport wrote: > khugepaged does skip over VMAs which have userfault. We could register the > regions with userfault before populating them to avoid collapses in the > transition period. But then we'll have to populate these regions with >

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed, May 24, 2017 at 04:54:38PM +0200, Vlastimil Babka wrote: > On 05/24/2017 04:28 PM, Pavel Emelyanov wrote: > > On 05/24/2017 02:31 PM, Vlastimil Babka wrote: > >> On 05/24/2017 12:39 PM, Mike Rapoport wrote: > Hm so the prctl does: > > if (arg2) >

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed, May 24, 2017 at 04:54:38PM +0200, Vlastimil Babka wrote: > On 05/24/2017 04:28 PM, Pavel Emelyanov wrote: > > On 05/24/2017 02:31 PM, Vlastimil Babka wrote: > >> On 05/24/2017 12:39 PM, Mike Rapoport wrote: > Hm so the prctl does: > > if (arg2) >

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On 05/24/2017 04:28 PM, Pavel Emelyanov wrote: > On 05/24/2017 02:31 PM, Vlastimil Babka wrote: >> On 05/24/2017 12:39 PM, Mike Rapoport wrote: Hm so the prctl does: if (arg2) me->mm->def_flags |= VM_NOHUGEPAGE; else

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On 05/24/2017 04:28 PM, Pavel Emelyanov wrote: > On 05/24/2017 02:31 PM, Vlastimil Babka wrote: >> On 05/24/2017 12:39 PM, Mike Rapoport wrote: Hm so the prctl does: if (arg2) me->mm->def_flags |= VM_NOHUGEPAGE; else

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On 05/24/2017 02:31 PM, Vlastimil Babka wrote: > On 05/24/2017 12:39 PM, Mike Rapoport wrote: >>> Hm so the prctl does: >>> >>> if (arg2) >>> me->mm->def_flags |= VM_NOHUGEPAGE; >>> else >>> me->mm->def_flags &=

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On 05/24/2017 02:31 PM, Vlastimil Babka wrote: > On 05/24/2017 12:39 PM, Mike Rapoport wrote: >>> Hm so the prctl does: >>> >>> if (arg2) >>> me->mm->def_flags |= VM_NOHUGEPAGE; >>> else >>> me->mm->def_flags &=

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed, May 24, 2017 at 01:18:00PM +0200, Michal Hocko wrote: > On Wed 24-05-17 13:39:48, Mike Rapoport wrote: > > On Wed, May 24, 2017 at 09:58:06AM +0200, Vlastimil Babka wrote: > > > On 05/24/2017 09:50 AM, Mike Rapoport wrote: > > > > On Mon, May 22, 2017 at 05:52:47PM +0200, Vlastimil Babka

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed, May 24, 2017 at 01:18:00PM +0200, Michal Hocko wrote: > On Wed 24-05-17 13:39:48, Mike Rapoport wrote: > > On Wed, May 24, 2017 at 09:58:06AM +0200, Vlastimil Babka wrote: > > > On 05/24/2017 09:50 AM, Mike Rapoport wrote: > > > > On Mon, May 22, 2017 at 05:52:47PM +0200, Vlastimil Babka

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On 05/24/2017 02:18 PM, Michal Hocko wrote: > On Wed 24-05-17 13:39:48, Mike Rapoport wrote: >> On Wed, May 24, 2017 at 09:58:06AM +0200, Vlastimil Babka wrote: >>> On 05/24/2017 09:50 AM, Mike Rapoport wrote: On Mon, May 22, 2017 at 05:52:47PM +0200, Vlastimil Babka wrote: > On

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On 05/24/2017 02:18 PM, Michal Hocko wrote: > On Wed 24-05-17 13:39:48, Mike Rapoport wrote: >> On Wed, May 24, 2017 at 09:58:06AM +0200, Vlastimil Babka wrote: >>> On 05/24/2017 09:50 AM, Mike Rapoport wrote: On Mon, May 22, 2017 at 05:52:47PM +0200, Vlastimil Babka wrote: > On

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On 05/24/2017 12:39 PM, Mike Rapoport wrote: >> Hm so the prctl does: >> >> if (arg2) >> me->mm->def_flags |= VM_NOHUGEPAGE; >> else >> me->mm->def_flags &= ~VM_NOHUGEPAGE; >> >> That's rather lazy implementation IMHO.

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On 05/24/2017 12:39 PM, Mike Rapoport wrote: >> Hm so the prctl does: >> >> if (arg2) >> me->mm->def_flags |= VM_NOHUGEPAGE; >> else >> me->mm->def_flags &= ~VM_NOHUGEPAGE; >> >> That's rather lazy implementation IMHO.

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed 24-05-17 13:39:48, Mike Rapoport wrote: > On Wed, May 24, 2017 at 09:58:06AM +0200, Vlastimil Babka wrote: > > On 05/24/2017 09:50 AM, Mike Rapoport wrote: > > > On Mon, May 22, 2017 at 05:52:47PM +0200, Vlastimil Babka wrote: > > >> On 05/22/2017 04:29 PM, Mike Rapoport wrote: > > >>> > >

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed 24-05-17 13:39:48, Mike Rapoport wrote: > On Wed, May 24, 2017 at 09:58:06AM +0200, Vlastimil Babka wrote: > > On 05/24/2017 09:50 AM, Mike Rapoport wrote: > > > On Mon, May 22, 2017 at 05:52:47PM +0200, Vlastimil Babka wrote: > > >> On 05/22/2017 04:29 PM, Mike Rapoport wrote: > > >>> > >

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed, May 24, 2017 at 09:58:06AM +0200, Vlastimil Babka wrote: > On 05/24/2017 09:50 AM, Mike Rapoport wrote: > > On Mon, May 22, 2017 at 05:52:47PM +0200, Vlastimil Babka wrote: > >> On 05/22/2017 04:29 PM, Mike Rapoport wrote: > >>> > >>> Probably I didn't explained it too well. > >>> > >>>

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Wed, May 24, 2017 at 09:58:06AM +0200, Vlastimil Babka wrote: > On 05/24/2017 09:50 AM, Mike Rapoport wrote: > > On Mon, May 22, 2017 at 05:52:47PM +0200, Vlastimil Babka wrote: > >> On 05/22/2017 04:29 PM, Mike Rapoport wrote: > >>> > >>> Probably I didn't explained it too well. > >>> > >>>

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On 05/24/2017 09:50 AM, Mike Rapoport wrote: > On Mon, May 22, 2017 at 05:52:47PM +0200, Vlastimil Babka wrote: >> On 05/22/2017 04:29 PM, Mike Rapoport wrote: >>> On Mon, May 22, 2017 at 03:55:48PM +0200, Michal Hocko wrote: On Mon 22-05-17 16:36:00, Mike Rapoport wrote: > On Mon, May

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On 05/24/2017 09:50 AM, Mike Rapoport wrote: > On Mon, May 22, 2017 at 05:52:47PM +0200, Vlastimil Babka wrote: >> On 05/22/2017 04:29 PM, Mike Rapoport wrote: >>> On Mon, May 22, 2017 at 03:55:48PM +0200, Michal Hocko wrote: On Mon 22-05-17 16:36:00, Mike Rapoport wrote: > On Mon, May

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Mon, May 22, 2017 at 05:52:47PM +0200, Vlastimil Babka wrote: > On 05/22/2017 04:29 PM, Mike Rapoport wrote: > > On Mon, May 22, 2017 at 03:55:48PM +0200, Michal Hocko wrote: > >> On Mon 22-05-17 16:36:00, Mike Rapoport wrote: > >>> On Mon, May 22, 2017 at 02:42:43PM +0300, Kirill A. Shutemov

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Mon, May 22, 2017 at 05:52:47PM +0200, Vlastimil Babka wrote: > On 05/22/2017 04:29 PM, Mike Rapoport wrote: > > On Mon, May 22, 2017 at 03:55:48PM +0200, Michal Hocko wrote: > >> On Mon 22-05-17 16:36:00, Mike Rapoport wrote: > >>> On Mon, May 22, 2017 at 02:42:43PM +0300, Kirill A. Shutemov

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Mon, May 22, 2017 at 05:52:47PM +0200, Vlastimil Babka wrote: > On 05/22/2017 04:29 PM, Mike Rapoport wrote: > > On Mon, May 22, 2017 at 03:55:48PM +0200, Michal Hocko wrote: > >> On Mon 22-05-17 16:36:00, Mike Rapoport wrote: > >>> On Mon, May 22, 2017 at 02:42:43PM +0300, Kirill A. Shutemov

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Mon, May 22, 2017 at 05:52:47PM +0200, Vlastimil Babka wrote: > On 05/22/2017 04:29 PM, Mike Rapoport wrote: > > On Mon, May 22, 2017 at 03:55:48PM +0200, Michal Hocko wrote: > >> On Mon 22-05-17 16:36:00, Mike Rapoport wrote: > >>> On Mon, May 22, 2017 at 02:42:43PM +0300, Kirill A. Shutemov

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On 05/22/2017 04:29 PM, Mike Rapoport wrote: > On Mon, May 22, 2017 at 03:55:48PM +0200, Michal Hocko wrote: >> On Mon 22-05-17 16:36:00, Mike Rapoport wrote: >>> On Mon, May 22, 2017 at 02:42:43PM +0300, Kirill A. Shutemov wrote: On Mon, May 22, 2017 at 09:12:42AM +0300, Mike Rapoport wrote:

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On 05/22/2017 04:29 PM, Mike Rapoport wrote: > On Mon, May 22, 2017 at 03:55:48PM +0200, Michal Hocko wrote: >> On Mon 22-05-17 16:36:00, Mike Rapoport wrote: >>> On Mon, May 22, 2017 at 02:42:43PM +0300, Kirill A. Shutemov wrote: On Mon, May 22, 2017 at 09:12:42AM +0300, Mike Rapoport wrote:

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

Hi Mike, [auto build test ERROR on mmotm/master] [also build test ERROR on v4.12-rc2 next-20170522] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

Hi Mike, [auto build test ERROR on mmotm/master] [also build test ERROR on v4.12-rc2 next-20170522] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Mon, May 22, 2017 at 03:55:48PM +0200, Michal Hocko wrote: > On Mon 22-05-17 16:36:00, Mike Rapoport wrote: > > On Mon, May 22, 2017 at 02:42:43PM +0300, Kirill A. Shutemov wrote: > > > On Mon, May 22, 2017 at 09:12:42AM +0300, Mike Rapoport wrote: > > > > Currently applications can explicitly

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Mon, May 22, 2017 at 03:55:48PM +0200, Michal Hocko wrote: > On Mon 22-05-17 16:36:00, Mike Rapoport wrote: > > On Mon, May 22, 2017 at 02:42:43PM +0300, Kirill A. Shutemov wrote: > > > On Mon, May 22, 2017 at 09:12:42AM +0300, Mike Rapoport wrote: > > > > Currently applications can explicitly

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Mon 22-05-17 16:36:00, Mike Rapoport wrote: > On Mon, May 22, 2017 at 02:42:43PM +0300, Kirill A. Shutemov wrote: > > On Mon, May 22, 2017 at 09:12:42AM +0300, Mike Rapoport wrote: > > > Currently applications can explicitly enable or disable THP for a memory > > > region using MADV_HUGEPAGE or

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Mon 22-05-17 16:36:00, Mike Rapoport wrote: > On Mon, May 22, 2017 at 02:42:43PM +0300, Kirill A. Shutemov wrote: > > On Mon, May 22, 2017 at 09:12:42AM +0300, Mike Rapoport wrote: > > > Currently applications can explicitly enable or disable THP for a memory > > > region using MADV_HUGEPAGE or

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Mon, May 22, 2017 at 04:36:00PM +0300, Mike Rapoport wrote: > On Mon, May 22, 2017 at 02:42:43PM +0300, Kirill A. Shutemov wrote: > > On Mon, May 22, 2017 at 09:12:42AM +0300, Mike Rapoport wrote: > > > Currently applications can explicitly enable or disable THP for a memory > > > region using

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Mon, May 22, 2017 at 04:36:00PM +0300, Mike Rapoport wrote: > On Mon, May 22, 2017 at 02:42:43PM +0300, Kirill A. Shutemov wrote: > > On Mon, May 22, 2017 at 09:12:42AM +0300, Mike Rapoport wrote: > > > Currently applications can explicitly enable or disable THP for a memory > > > region using

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Mon, May 22, 2017 at 02:42:43PM +0300, Kirill A. Shutemov wrote: > On Mon, May 22, 2017 at 09:12:42AM +0300, Mike Rapoport wrote: > > Currently applications can explicitly enable or disable THP for a memory > > region using MADV_HUGEPAGE or MADV_NOHUGEPAGE. However, once either of > > these

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Mon, May 22, 2017 at 02:42:43PM +0300, Kirill A. Shutemov wrote: > On Mon, May 22, 2017 at 09:12:42AM +0300, Mike Rapoport wrote: > > Currently applications can explicitly enable or disable THP for a memory > > region using MADV_HUGEPAGE or MADV_NOHUGEPAGE. However, once either of > > these

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Mon, May 22, 2017 at 09:12:42AM +0300, Mike Rapoport wrote: > Currently applications can explicitly enable or disable THP for a memory > region using MADV_HUGEPAGE or MADV_NOHUGEPAGE. However, once either of > these advises is used, the region will always have > VM_HUGEPAGE/VM_NOHUGEPAGE flag

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Mon, May 22, 2017 at 09:12:42AM +0300, Mike Rapoport wrote: > Currently applications can explicitly enable or disable THP for a memory > region using MADV_HUGEPAGE or MADV_NOHUGEPAGE. However, once either of > these advises is used, the region will always have > VM_HUGEPAGE/VM_NOHUGEPAGE flag

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Mon, May 22, 2017 at 12:56:45PM +0530, Anshuman Khandual wrote: > On 05/22/2017 11:42 AM, Mike Rapoport wrote: > > Currently applications can explicitly enable or disable THP for a memory > > region using MADV_HUGEPAGE or MADV_NOHUGEPAGE. However, once either of > > these advises is used, the

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On Mon, May 22, 2017 at 12:56:45PM +0530, Anshuman Khandual wrote: > On 05/22/2017 11:42 AM, Mike Rapoport wrote: > > Currently applications can explicitly enable or disable THP for a memory > > region using MADV_HUGEPAGE or MADV_NOHUGEPAGE. However, once either of > > these advises is used, the

  1   2   >