Hello Yu, We had some disagreements over this series last time around after which I had posted the following series [1] which tried to enable ARCH_ENABLE_SPLIT_PMD_PTLOCK after doing some pgtable accounting changes. After some thoughts and deliberations I figure that its better not to do pgtable alloc changes on arm64 creating a brand new semantics which ideally should be first debated and agreed upon in generic MM. Though I still see value in a changed generic pgtable page allocation semantics for user and kernel space that should not stop us from enabling more granular PMD level locks through ARCH_ENABLE_SPLIT_PMD_PTLOCK right now. [1] https://www.spinics.net/lists/arm-kernel/msg709917.html Having said that this series attempts to enable ARCH_ENABLE_SPLIT_PMD_PTLOCK with some minimal changes to existing kernel pgtable page allocation code. Hence just trying to re-evaluate the series in that isolation. On 03/10/2019 06:49 AM, Yu Zhao wrote: > For pte page, use pgtable_page_ctor(); for pmd page, use > pgtable_pmd_page_ctor(); and for the rest (pud, p4d and pgd), > don't use any. This is semantics change. Hence the question is why ? Should not we wait until a generic MM agreement in place in this regard ? Can we avoid this ? Is the change really required to enable ARCH_ENABLE_SPLIT_PMD_PTLOCK for user space THP which this series originally intended to achieve ? > > For now, we don't select ARCH_ENABLE_SPLIT_PMD_PTLOCK and > pgtable_pmd_page_ctor() is a nop. When we do in patch 3, we > make sure pmd is not folded so we won't mistakenly call > pgtable_pmd_page_ctor() on pud or p4d. This makes sense from code perspective but I still dont understand the need to change kernel pgtable page allocation semantics without any real benefit or fix at the moment. Cant we keep kernel page table page allocation unchanged for now and just enable ARCH_ENABLE_SPLIT_PMD_PTLOCK for user space THP benefits ? Do you see any concern with that.
