Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38;
MIME-Version: 1.0
References: <20231017154439.3036608-1-chengming.zhou@linux.dev>
In-Reply-To: <20231017154439.3036608-1-chengming.zhou@linux.dev>
From:   Hyeonggon Yoo <42.hyeyoo@gmail.com>
Date:   Wed, 18 Oct 2023 15:34:14 +0900
Message-ID: <CAB=+i9Sw1YSdUKrjygA5cOsVjQMVmS8-KJ+ku4AG9Fw_2guENQ@mail.gmail.com>
Subject: Re: [RFC PATCH 0/5] slub: Delay freezing of CPU partial slabs
To:     chengming.zhou@linux.dev
Cc:     cl@linux.com, penberg@kernel.org, rientjes@google.com,
        iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, vbabka@suse.cz,
        roman.gushchin@linux.dev, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org,
        Chengming Zhou <zhouchengming@bytedance.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Oct 18, 2023 at 12:45=E2=80=AFAM <chengming.zhou@linux.dev> wrote:
> 4. Testing
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> We just did some simple testing on a server with 128 CPUs (2 nodes) to
> compare performance for now.
>
>  - perf bench sched messaging -g 5 -t -l 100000
>    baseline     RFC
>    7.042s       6.966s
>    7.022s       7.045s
>    7.054s       6.985s
>
>  - stress-ng --rawpkt 128 --rawpkt-ops 100000000
>    baseline     RFC
>    2.42s        2.15s
>    2.45s        2.16s
>    2.44s        2.17s
>
> It shows above there is about 10% improvement on stress-ng rawpkt
> testcase, although no much improvement on perf sched bench testcase.
>
> Thanks for any comment and code review!

Hi Chengming, this is the kerneltesting.org test report for your patch seri=
es.

I applied this series on my slab-experimental tree [1] for testing,
and I observed several kernel panics [2] [3] [4] on kernels without
CONFIG_SLUB_CPU_PARTIAL.

To verify that this series caused kernel panics, I tested before and after
applying it on Vlastimil's slab/for-next and yeah, this series was the caus=
e.

System is deadlocked on memory and the OOM-killer says there is a
huge amount of slab memory. So maybe there is a memory leak or it makes
slab memory grow unboundedly?

[1] https://git.kerneltesting.org/slab-experimental/
[2] https://lava.kerneltesting.org/scheduler/job/127#bottom
[3] https://lava.kerneltesting.org/scheduler/job/131#bottom
[4] https://lava.kerneltesting.org/scheduler/job/134#bottom

>
> Chengming Zhou (5):
>   slub: Introduce on_partial()
>   slub: Don't manipulate slab list when used by cpu
>   slub: Optimize deactivate_slab()
>   slub: Don't freeze slabs for cpu partial
>   slub: Introduce get_cpu_partial()
>
>  mm/slab.h |   2 +-
>  mm/slub.c | 257 +++++++++++++++++++++++++++++++-----------------------
>  2 files changed, 150 insertions(+), 109 deletions(-)
>
> --
> 2.40.1
>