quoted
quoted
--- 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