[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <acf254e9-0207-7030-131f-8a3f520c657b@amd.com>
Date: Tue, 12 Sep 2023 12:13:08 +0530
From: Raghavendra K T <raghavendra.kt@....com>
To: Oliver Sang <oliver.sang@...el.com>
Cc: Mel Gorman <mgorman@...hsingularity.net>,
Peter Zijlstra <peterz@...radead.org>, oe-lkp@...ts.linux.dev,
lkp@...el.com, Bharata B Rao <bharata@....com>,
linux-kernel@...r.kernel.org, ying.huang@...el.com,
feng.tang@...el.com, fengwei.yin@...el.com,
aubrey.li@...ux.intel.com, yu.c.chen@...el.com, linux-mm@...ck.org,
Ingo Molnar <mingo@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
David Hildenbrand <david@...hat.com>, rppt@...nel.org,
Juri Lelli <juri.lelli@...hat.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Aithal Srikanth <sraithal@....com>,
Sapkal Swapnil <Swapnil.Sapkal@....com>,
K Prateek Nayak <kprateek.nayak@....com>
Subject: Re: [RFC PATCH V1 5/6] sched/numa: Allow recently accessed VMAs to be
scanned
On 9/12/2023 7:52 AM, Oliver Sang wrote:
> hi, Raghu,
>
> On Mon, Sep 11, 2023 at 04:55:56PM +0530, Raghavendra K T wrote:
>> On 9/10/2023 8:59 PM, kernel test robot wrote:
>>> 341.49 -4.1% 327.42 ± 2% autonuma-benchmark.numa01.seconds
>>> 186.67 ± 6% -27.1% 136.12 ± 7% autonuma-benchmark.numa01_THREAD_ALLOC.seconds
>>> 21.17 ± 7% -33.6% 14.05 autonuma-benchmark.numa02.seconds
>>> 2200 ± 2% -13.0% 1913 ± 3% autonuma-benchmark.time.elapsed_time
>>
>> Hello Oliver/Kernel test robot,
>> Thank yo alot for testing.
>>
>> Results are impressive. Can I take this result as
>> positive for whole series too?
>
> FYI. we applied your patch set like below:
>
> 68cfe9439a1ba (linux-review/Raghavendra-K-T/sched-numa-Move-up-the-access-pid-reset-logic/20230829-141007) sched/numa: Allow scanning of shared VMAs
> af46f3c9ca2d1 sched/numa: Allow recently accessed VMAs to be scanned
> 167773d1ddb5f sched/numa: Increase tasks' access history
> fc769221b2306 sched/numa: Remove unconditional scan logic using mm numa_scan_seq
> 1ef5cbb92bdb3 sched/numa: Add disjoint vma unconditional scan logic
> 2a806eab1c2e1 sched/numa: Move up the access pid reset logic
> 2f88c8e802c8b (tip/sched/core) sched/eevdf/doc: Modify the documented knob to base_slice_ns as well
>
> in our tests, we also tested the 68cfe9439a1ba, if comparing it to af46f3c9ca2d1:
>
> =========================================================================================
> compiler/cpufreq_governor/iterations/kconfig/rootfs/tbox_group/test/testcase:
> gcc-12/performance/4x/x86_64-rhel-8.3/debian-11.1-x86_64-20220510.cgz/lkp-icl-2sp6/numa01_THREAD_ALLOC/autonuma-benchmark
>
> commit:
> af46f3c9ca ("sched/numa: Allow recently accessed VMAs to be scanned")
> 68cfe9439a ("sched/numa: Allow scanning of shared VMA")
>
> af46f3c9ca2d1648 68cfe9439a1baa642e05883fa64
> ---------------- ---------------------------
> %stddev %change %stddev
> \ | \
> 327.42 ± 2% -1.1% 323.83 ± 3% autonuma-benchmark.numa01.seconds
> 136.12 ± 7% -25.1% 101.90 ± 2% autonuma-benchmark.numa01_THREAD_ALLOC.seconds
> 14.05 +1.5% 14.26 autonuma-benchmark.numa02.seconds
> 1913 ± 3% -7.9% 1763 ± 2% autonuma-benchmark.time.elapsed_time
>
>
> below is the full comparison FYI.
>
Thanks a lot for further run and details.
Combining this result with previous, we do have a very good
result overall for LKP.
167773d1dd ("sched/numa: Increase tasks' access history")
af46f3c9ca ("sched/numa: Allow recently accessed VMAs to be scanned")
167773d1ddb5ffdd af46f3c9ca2d16485912f8b9c89
---------------- ---------------------------
%stddev %change %stddev
341.49 -4.1% 327.42 ± 2% autonuma-benchmark.numa01.seconds
186.67 ± 6% -27.1% 136.12 ± 7%
autonuma-benchmark.numa01_THREAD_ALLOC.seconds
21.17 ± 7% -33.6% 14.05
autonuma-benchmark.numa02.seconds
2200 ± 2% -13.0% 1913 ± 3%
autonuma-benchmark.time.elapsed_time
Thanks and Regards
- Raghu
>
>
>
>>
>> Mel/PeterZ,
>>
>> Whenever time permits can you please let us know your comments/concerns
>> on the series?
>>
>> Thanks and Regards
>> - Raghu
>>
Powered by blists - more mailing lists