Re: [PATCH 3/3] mm/page_alloc: Introduce a new sysctl knob vm.pcp_batch_scale_max

[Yafang Shao <laoar.shao@gmail.com>]

On Wed, Jul 10, 2024 at 10:51 AM Huang, Ying <ying.huang@intel.com> wrote:
>
> Yafang Shao <laoar.shao@gmail.com> 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