On Tue, Feb 08, 2022 at 01:18:59AM -0700, Yu Zhao wrote: > Add /sys/kernel/mm/lru_gen/enabled as a runtime switch. Features that > can be enabled or disabled include: > 0x0001: the multigenerational LRU > 0x0002: the page table walks, when arch_has_hw_pte_young() returns > true > 0x0004: the use of the accessed bit in non-leaf PMD entries, when > CONFIG_ARCH_HAS_NONLEAF_PMD_YOUNG=y > [yYnN]: apply to all the features above > E.g., > echo y >/sys/kernel/mm/lru_gen/enabled > cat /sys/kernel/mm/lru_gen/enabled > 0x0007 > echo 5 >/sys/kernel/mm/lru_gen/enabled > cat /sys/kernel/mm/lru_gen/enabled > 0x0005 > > NB: the page table walks happen on the scale of seconds under heavy > memory pressure. Under such a condition, the mmap_lock contention is a > lesser concern, compared with the LRU lock contention and the I/O > congestion. So far the only well-known case of the mmap_lock > contention is Android, due to Scudo [1] which allocates several > thousand VMAs for merely a few hundred MBs. The SPF and the Maple Tree > also have provided their own assessments [2][3]. However, if the page > table walks do worsen the mmap_lock contention, the runtime switch can > be used to disable this feature. In this case the multigenerational > LRU will suffer a minor performance degradation, as shown previously. Clarified the potential impact from the mmap_lock contention as requested here: https://lore.kernel.org/linux-mm/YdwQcl6D5Mbp9Z4h@xxxxxxxxxxxxxx/ <snipped> > +static void lru_gen_change_state(bool enable) > +{ > + static DEFINE_MUTEX(state_mutex); > + > + struct mem_cgroup *memcg; > + > + cgroup_lock(); > + cpus_read_lock(); > + get_online_mems(); > + mutex_lock(&state_mutex); > + > + if (enable == lru_gen_enabled()) > + goto unlock; > + > + if (enable) > + static_branch_enable_cpuslocked(&lru_gen_caps[LRU_GEN_CORE]); > + else > + static_branch_disable_cpuslocked(&lru_gen_caps[LRU_GEN_CORE]); Fixed the lockdep warning for memory hotplug: https://lore.kernel.org/linux-mm/87a6g0nczg.fsf@xxxxxxxxxxxxx/ <snipped>
