[PATCH v4] mm: introduce reference pages
David Hildenbrand
david at redhat.com
Tue Jul 20 00:28:31 PDT 2021
>>> --- 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
More information about the linux-arm-kernel
mailing list