On Wed, Jul 10, 2024 at 10:51 AM Huang, Ying <ying.huang@xxxxxxxxx> wrote: > > Yafang Shao <laoar.shao@xxxxxxxxx> writes: > > > The configuration parameter PCP_BATCH_SCALE_MAX poses challenges for > > quickly experimenting with specific workloads in a production environment, > > particularly when monitoring latency spikes caused by contention on the > > zone->lock. To address this, a new sysctl parameter vm.pcp_batch_scale_max > > is introduced as a more practical alternative. > > In general, I'm neutral to the change. I can understand that kernel > configuration isn't as flexible as sysctl knob. But, sysctl knob is ABI > too. > > > To ultimately mitigate the zone->lock contention issue, several suggestions > > have been proposed. One approach involves dividing large zones into multi > > smaller zones, as suggested by Matthew[0], while another entails splitting > > the zone->lock using a mechanism similar to memory arenas and shifting away > > from relying solely on zone_id to identify the range of free lists a > > particular page belongs to[1]. However, implementing these solutions is > > likely to necessitate a more extended development effort. > > Per my understanding, the change will hurt instead of improve zone->lock > contention. Instead, it will reduce page allocation/freeing latency. I'm quite perplexed by your recent comment. You introduced a configuration that has proven to be difficult to use, and you have been resistant to suggestions for modifying it to a more user-friendly and practical tuning approach. May I inquire about the rationale behind introducing this configuration in the beginning? -- Regards Yafang
