Re: [linux-next:master] [memcg] 70a64b7919: will-it-scale.per_process_ops -11.9% regression

[Shakeel Butt <shakeel.butt@linux.dev>]

On Thu, May 23, 2024 at 03:48:40PM +0800, Oliver Sang wrote:
> hi, Shakeel,
> 
> On Tue, May 21, 2024 at 09:18:19PM -0700, Shakeel Butt wrote:
> > On Tue, May 21, 2024 at 10:43:16AM +0800, Oliver Sang wrote:
> > > hi, Shakeel,
> > > 
> > [...]
> > > 
> > > we reported regression on a 2-node Skylake server. so I found a 1-node Skylake
> > > desktop (we don't have 1 node server) to check.
> > > 
> > 
> > Please try the following patch on both single node and dual node
> > machines:
> 
> 
> the regression is partially recovered by applying your patch.
> (but one even more regression case as below)
> 
> details:
> 
> since you mentioned the whole patch-set behavior last time, I applied the
> patch upon
>   a94032b35e5f9 memcg: use proper type for mod_memcg_state
> 
> below fd2296741e2686ed6ecd05187e4 = a94032b35e5f9 + patch
> 

Thanks a lot Oliver. I have couple of questions and requests:

1. What is the baseline kernel you are using? Is it linux-next or linus?
If linux-next, which one specifically?

2. What is the cgroup hierarchy where the workload is running? Is it
running in the root cgroup?

3. For the followup experiments when needed, can you please remove the
whole series (including 59142d87ab03b8ff) for the base numbers.

4. My experiment [1] on Cooper Lake (2 node) and Skylake (1 node) shows
significant improvement but I noticed that I am directly running
page_fault2_processes with -t equal nr_cpus but you are running through
runtest.py. Also it seems like lkp has modified runtest.py. I will try
to run the same setup as yours to repro.


[1] https://lore.kernel.org/all/20240523034824.1255719-1-shakeel.butt@linux.dev

thanks,
Shakeel