On Tue, 22 Aug 2023, Matthew Wilcox wrote: > On Tue, Aug 22, 2023 at 11:34:19AM -0700, Hugh Dickins wrote: > > (Yes, the locking is a bit confusing: but mainly for the unrelated reason, > > that with the split locking configs, we never quite know whether this lock > > is the same as that lock or not, and so have to be rather careful.) > > Is it time to remove the PTE split locking config option? I believe all > supported architectures have at least two levels of page tables, so if we > have split ptlocks, ptl and pml are always different from each other (it's > just that on two level machines, pmd == pud == p4d == pgd). With huge > thread counts now being the norm, it's hard to see why anybody would want > to support SMP and !SPLIT_PTE_PTLOCKS. To quote the documentation ... > > Split page table lock for PTE tables is enabled compile-time if > CONFIG_SPLIT_PTLOCK_CPUS (usually 4) is less or equal to NR_CPUS. > If split lock is disabled, all tables are guarded by mm->page_table_lock. > > You can barely buy a wrist-watch without eight CPUs these days. Whilst I'm still happy with my 0-CPU wrist-watch, I do think you're right: that SPLIT_PTLOCK_CPUS business was really just a safety-valve for when introducing split ptlock in the first place, 4 pulled out of a hat, and the unsplit ptlock path quite under-tested. But I'll leave it to someone else do the job of removing it whenever. Hugh
