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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <52bed78b-e7ac-49af-886c-df15968f1c74@huaweicloud.com>
Date: Tue, 10 Sep 2024 11:16:30 +0800
From: Chen Ridong <chenridong@...weicloud.com>
To: Michal Koutný <mkoutny@...e.com>,
 Chen Ridong <chenridong@...wei.com>
Cc: tj@...nel.org, lizefan.x@...edance.com, hannes@...xchg.org,
 longman@...hat.com, adityakali@...gle.com, sergeh@...nel.org,
 cgroups@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 -next 0/3] Some optimizations about freezer



On 2024/9/10 3:04, Michal Koutný wrote:
> Hello.
> 
> On Thu, Sep 05, 2024 at 01:41:27PM GMT, Chen Ridong <chenridong@...wei.com> 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