Re: [PATCH] mm: make PR_SET_THP_DISABLE immediately active

On 06/02/2017 11:10 PM, Andrew Morton wrote: > On Fri, 2 Jun 2017 22:55:12 +0200 Vlastimil Babka wrote: > >> On 06/02/2017 10:40 PM, Andrew Morton wrote: >>> On Fri, 2 Jun 2017 22:31:47 +0200 Vlastimil Babka wrote: > Perhaps we should be adding new prctl

Re: [PATCH] mm: make PR_SET_THP_DISABLE immediately active

On 06/02/2017 11:10 PM, Andrew Morton wrote: > On Fri, 2 Jun 2017 22:55:12 +0200 Vlastimil Babka wrote: > >> On 06/02/2017 10:40 PM, Andrew Morton wrote: >>> On Fri, 2 Jun 2017 22:31:47 +0200 Vlastimil Babka wrote: > Perhaps we should be adding new prctl modes to select this new >

Re: [PATCH] mm: make PR_SET_THP_DISABLE immediately active

On Sat, Jun 03, 2017 at 01:34:52PM +0300, Mike Rapoprt wrote: > > > On June 2, 2017 11:55:12 PM GMT+03:00, Vlastimil Babka wrote: > >On 06/02/2017 10:40 PM, Andrew Morton wrote: > >> On Fri, 2 Jun 2017 22:31:47 +0200 Vlastimil Babka > >wrote: > Perhaps we

Re: [PATCH] mm: make PR_SET_THP_DISABLE immediately active

On Sat, Jun 03, 2017 at 01:34:52PM +0300, Mike Rapoprt wrote: > > > On June 2, 2017 11:55:12 PM GMT+03:00, Vlastimil Babka wrote: > >On 06/02/2017 10:40 PM, Andrew Morton wrote: > >> On Fri, 2 Jun 2017 22:31:47 +0200 Vlastimil Babka > >wrote: > Perhaps we should be adding new prctl modes

Re: [PATCH] mm: make PR_SET_THP_DISABLE immediately active

On June 2, 2017 10:50:59 PM GMT+03:00, Andrew Morton wrote: >On Fri, 2 Jun 2017 18:03:22 +0300 "Mike Rapoport" > wrote: > >> PR_SET_THP_DISABLE has a rather subtle semantic. It doesn't affect >any >> existing mapping because it only updated

Re: [PATCH] mm: make PR_SET_THP_DISABLE immediately active

On June 2, 2017 10:50:59 PM GMT+03:00, Andrew Morton wrote: >On Fri, 2 Jun 2017 18:03:22 +0300 "Mike Rapoport" > wrote: > >> PR_SET_THP_DISABLE has a rather subtle semantic. It doesn't affect >any >> existing mapping because it only updated mm->def_flags which is a >template >> for new

Re: [PATCH] mm: make PR_SET_THP_DISABLE immediately active

On June 2, 2017 11:55:12 PM GMT+03:00, Vlastimil Babka wrote: >On 06/02/2017 10:40 PM, Andrew Morton wrote: >> On Fri, 2 Jun 2017 22:31:47 +0200 Vlastimil Babka >wrote: Perhaps we should be adding new prctl modes to select this new behaviour and leave

Re: [PATCH] mm: make PR_SET_THP_DISABLE immediately active

On June 2, 2017 11:55:12 PM GMT+03:00, Vlastimil Babka wrote: >On 06/02/2017 10:40 PM, Andrew Morton wrote: >> On Fri, 2 Jun 2017 22:31:47 +0200 Vlastimil Babka >wrote: Perhaps we should be adding new prctl modes to select this new behaviour and leave the existing PR_SET_THP_DISABLE

Re: [PATCH] mm: make PR_SET_THP_DISABLE immediately active

On Fri 02-06-17 13:40:38, Andrew Morton wrote: > On Fri, 2 Jun 2017 22:31:47 +0200 Vlastimil Babka wrote: > > > On 06/02/2017 09:50 PM, Andrew Morton wrote: > > > On Fri, 2 Jun 2017 18:03:22 +0300 "Mike Rapoport" > > > wrote: > > > > > >>

Re: [PATCH] mm: make PR_SET_THP_DISABLE immediately active

On Fri 02-06-17 13:40:38, Andrew Morton wrote: > On Fri, 2 Jun 2017 22:31:47 +0200 Vlastimil Babka wrote: > > > On 06/02/2017 09:50 PM, Andrew Morton wrote: > > > On Fri, 2 Jun 2017 18:03:22 +0300 "Mike Rapoport" > > > wrote: > > > > > >> PR_SET_THP_DISABLE has a rather subtle semantic. It

Re: [PATCH] mm: make PR_SET_THP_DISABLE immediately active

On Fri, 2 Jun 2017 22:55:12 +0200 Vlastimil Babka wrote: > On 06/02/2017 10:40 PM, Andrew Morton wrote: > > On Fri, 2 Jun 2017 22:31:47 +0200 Vlastimil Babka wrote: > >>> Perhaps we should be adding new prctl modes to select this new > >>> behaviour and leave the

Re: [PATCH] mm: make PR_SET_THP_DISABLE immediately active

On Fri, 2 Jun 2017 22:55:12 +0200 Vlastimil Babka wrote: > On 06/02/2017 10:40 PM, Andrew Morton wrote: > > On Fri, 2 Jun 2017 22:31:47 +0200 Vlastimil Babka wrote: > >>> Perhaps we should be adding new prctl modes to select this new > >>> behaviour and leave the existing PR_SET_THP_DISABLE

Re: [PATCH] mm: make PR_SET_THP_DISABLE immediately active

On 06/02/2017 10:40 PM, Andrew Morton wrote: > On Fri, 2 Jun 2017 22:31:47 +0200 Vlastimil Babka wrote: >>> Perhaps we should be adding new prctl modes to select this new >>> behaviour and leave the existing PR_SET_THP_DISABLE behaviour as-is? >> >> I think we can reasonably

Re: [PATCH] mm: make PR_SET_THP_DISABLE immediately active

On 06/02/2017 10:40 PM, Andrew Morton wrote: > On Fri, 2 Jun 2017 22:31:47 +0200 Vlastimil Babka wrote: >>> Perhaps we should be adding new prctl modes to select this new >>> behaviour and leave the existing PR_SET_THP_DISABLE behaviour as-is? >> >> I think we can reasonably assume that most

Re: [PATCH] mm: make PR_SET_THP_DISABLE immediately active

On Fri, 2 Jun 2017 22:31:47 +0200 Vlastimil Babka wrote: > On 06/02/2017 09:50 PM, Andrew Morton wrote: > > On Fri, 2 Jun 2017 18:03:22 +0300 "Mike Rapoport" > > wrote: > > > >> PR_SET_THP_DISABLE has a rather subtle semantic. It doesn't affect any >

Re: [PATCH] mm: make PR_SET_THP_DISABLE immediately active

On Fri, 2 Jun 2017 22:31:47 +0200 Vlastimil Babka wrote: > On 06/02/2017 09:50 PM, Andrew Morton wrote: > > On Fri, 2 Jun 2017 18:03:22 +0300 "Mike Rapoport" > > wrote: > > > >> PR_SET_THP_DISABLE has a rather subtle semantic. It doesn't affect any > >> existing mapping because it only

Re: [PATCH] mm: make PR_SET_THP_DISABLE immediately active

On 06/02/2017 09:50 PM, Andrew Morton wrote: > On Fri, 2 Jun 2017 18:03:22 +0300 "Mike Rapoport" > wrote: > >> PR_SET_THP_DISABLE has a rather subtle semantic. It doesn't affect any >> existing mapping because it only updated mm->def_flags which is a template >> for

Re: [PATCH] mm: make PR_SET_THP_DISABLE immediately active

On 06/02/2017 09:50 PM, Andrew Morton wrote: > On Fri, 2 Jun 2017 18:03:22 +0300 "Mike Rapoport" > wrote: > >> PR_SET_THP_DISABLE has a rather subtle semantic. It doesn't affect any >> existing mapping because it only updated mm->def_flags which is a template >> for new mappings. The mappings

Re: [PATCH] mm: make PR_SET_THP_DISABLE immediately active

On Fri, 2 Jun 2017 18:03:22 +0300 "Mike Rapoport" wrote: > PR_SET_THP_DISABLE has a rather subtle semantic. It doesn't affect any > existing mapping because it only updated mm->def_flags which is a template > for new mappings. The mappings created after

Re: [PATCH] mm: make PR_SET_THP_DISABLE immediately active

On Fri, 2 Jun 2017 18:03:22 +0300 "Mike Rapoport" wrote: > PR_SET_THP_DISABLE has a rather subtle semantic. It doesn't affect any > existing mapping because it only updated mm->def_flags which is a template > for new mappings. The mappings created after prctl(PR_SET_THP_DISABLE) have >

[PATCH] mm: make PR_SET_THP_DISABLE immediately active

From: Michal Hocko PR_SET_THP_DISABLE has a rather subtle semantic. It doesn't affect any existing mapping because it only updated mm->def_flags which is a template for new mappings. The mappings created after prctl(PR_SET_THP_DISABLE) have VM_NOHUGEPAGE flag set. This can be

[PATCH] mm: make PR_SET_THP_DISABLE immediately active

From: Michal Hocko PR_SET_THP_DISABLE has a rather subtle semantic. It doesn't affect any existing mapping because it only updated mm->def_flags which is a template for new mappings. The mappings created after prctl(PR_SET_THP_DISABLE) have VM_NOHUGEPAGE flag set. This can be quite surprising