> Why cannot we do something similar to the optimized struct page > initialization and write 8B at the time and fill up the size unaligned > chunk in 1B? I do not think this is a good idea: memset() on SPARC is slow for small sizes, this is why we ended up using stores, but thats not the case on x86 where memset() is well optimized for small sizes. So, I believe we will see regressions. But even without the regressions there are several reasons why I think this is not a good idea: 1. struct page size vary depending on configs. So, in order to create a pattern that looks like a valid struct page, we would need to figure out what is our struct page size. 2. memblock allocator is totally independent from struct pages, it is going to be strange to add this dependency. The allocatoted memory is also used for page tables, and kasan, so we do not really know where the pattern should start from the allocator point of view. 3. It is going to be too easy to break that pattern if something changes or shifts: struct page changes, vmemmap allocations change or anything else. Overall, I think now we have a good coverage now: CONFIG_DEBUG_VM option tests for totally invalid struct pages, and kexec tests for struct pages that look like valid ones, but they are invalid because from the previous instance of kernel. Pasha -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
