# Re: \[PATCH v4\] mm: introduce reference pages

- From: David Hildenbrand \<hidden\>
- Date: 2021-07-20 07:28:38 
- List: linux-arm-kernel
- Page: https://ratatoskr.run/linux-arm-kernel/2021/07/6509960
- Thread: https://ratatoskr.run/linux-arm-kernel/2021/06/6508943/t.md

```text

>>> --- a/include/linux/gfp.h
>>> +++ b/include/linux/gfp.h
>>> @@ -55,8 +55,9 @@ struct vm_area_struct;
>>>    #define ___GFP_ACCOUNT              0x400000u
>>>    #define ___GFP_ZEROTAGS             0x800000u
>>>    #define ___GFP_SKIP_KASAN_POISON    0x1000000u
>>> +#define ___GFP_NOZERO                0x2000000u
>>
>> Oh god, please no. We've discussed this a couple of times already:
>> whatever leaves the page allcoator shall be zeroed. No exceptions, not
>> even for other allocators (like hugetlb).
>>
>> Introducing something like that to the whole system, including random
>> drivers, destroys the whole purpose of the security feature. Please
>> don't burry something so controversial in your patch.
>
> Got it -- I was unaware that this was controversial.
>
> Avoiding the double initialization does help a bit in benchmarks, at
> least for the fully faulted case. The alternative approach that I was
> thinking of was to somehow plumb the required pattern into the page
> allocator (which would maintain the invariant that the pages are
> initialized, but not necessarily with zeroes), but this would require
> touching several layers of the allocator.  I suppose that this doesn't
> need to be done immediately though -- we can deal with the double
> initialization for now and avoid it somehow in a followup.

As it's a clear optimization, it should definitely be separated from this "introduction" patch.

I agree that the logic for optimizing initialization of a page in this case should best reside in page_alloc.c, for example providing a helper for optimizing the initialization in there. We already pass alloc_flags internally, maybe we can then reuse that to minimize changes.

-- 
Thanks,

David / dhildenb


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
```