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
> behavi
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 t
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 mapping
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 b
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 do
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 beha
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 users
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 update
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 c
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
> VM_NOHUG
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 fo
11 matches
Mail list logo
