Re: [PATCH v1 -next 0/3] Some optimizations about freezer

[Chen Ridong]

On 2024/9/10 3:04, Michal Koutný wrote:
> Hello.
>
> On Thu, Sep 05, 2024 at 01:41:27PM GMT, Chen Ridong <chenridong@xxxxxxxxxx> wrote:
> > We optimized the freezer to reduce redundant loops. We add a selftest to
> > ensure our optimizations cause no harm, and we confirmed that the
> > performance can be improved.
>
> I think these patches have potential to make the code also cleaner and
> better to understand (the numbers from optimization don't impress me
> that much at the moment).
>
> I post more comments on the individual patches.
Thanks.

> > We tested the following subtree: D, E, F and G each have n children.
> >          A
> >         / \
> >        B   C
> >      / | \  \
> >      D E F   G
> >     /  |  \   \
> >   1-n 1-n 1-n  0-n
>
> (Why is the last one different?)
Sorry, this should be same.

> > Our test is to freeze A B C D E F G, and then unfreeze A B C D E F G.
>
> I would say measuring freezing/unfreezing of only A would give better
> idea about the impact of the change.
> (Going through all descendants manually would unfairly show greater
> improvement.)

I will add this test.
And I only test freezing/unfreezing A, The first patch may not be effective.

> > We measured the elapsed time.
> >
> > 	BEFORE(ns)	AFTER(ns)	SAVED(ns)
> > n=10	142679950	139666014	3,013,936
> > n=100	199832160	192773032	7,059,128
> > n=1000	488595100	414901570	73,693,530
>
> How many tasks were there inside cgroups in this benchmark?
I didn't put tasks inside cgroups to test. Because this series didn't 
change how the tasks be froze. That only reduced some redundant loop.


> (I assume in practice the freezing time would be dominated by waiting
> for tasks' response, so it'd be good to note this beside this result.)
>
> Thanks,
> Michal