* [PATCH] perf: optimize clear page in Intel specified model with movq instruction
@ 2021-09-09 8:45 Jinhua Wu
2021-09-09 9:39 ` Borislav Petkov
0 siblings, 1 reply; 10+ messages in thread
From: Jinhua Wu @ 2021-09-09 8:45 UTC (permalink / raw)
To: x86
Cc: zelin.deng, jiayu.ni, wujinhua, ak, luming.yu, fan.du,
artie.ding, tony.luck, tglx, bp, linux-kernel, pawan.kumar.gupta,
fenghua.yu, hpa, ricardo.neri-calderon, peterz
Clear page is the most time-consuming procedure in page fault handling.
Kernel use fast-string instruction to clear page. We found that in specified
Intel model such as CPX and ICX, the movq instruction perform much better
than fast-string instruction when corresponding page is not in cache.
But when the page is in cache, fast string perform better. We show the test
result in the following:
machine: Intel CPX
Allocated memory size Page fault latency per 4K byte
rep stosb movq
-------------------- ---------------- ------------------
8MB 2057.13ns 1338.38ns
64MB 1850.71ns 1200.20ns
512MB 1918.40ns 1196.91ns
4096MB 1931.24ns 1189.41ns
We can find that there is 40% performance improvement. So we add a blacklist
for Intel specified model, in which we use movq instruction to clear page.
Signed-off-by: Jinhua Wu <wujinhua@linux.alibaba.com>
Signed-off-by: Jiayu Ni <jiayu.ni@linux.alibaba.com>
Signed-off-by: Artie Ding <artie.ding@linux.alibaba.com>
---
arch/x86/include/asm/page_64.h | 18 ++++++++++++------
arch/x86/kernel/cpu/intel.c | 22 ++++++++++++++++++++++
arch/x86/mm/init.c | 9 +++++++++
3 files changed, 43 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/page_64.h b/arch/x86/include/asm/page_64.h
index 4bde0dc..1fedfbe 100644
--- a/arch/x86/include/asm/page_64.h
+++ b/arch/x86/include/asm/page_64.h
@@ -7,6 +7,8 @@
#ifndef __ASSEMBLY__
#include <asm/alternative.h>
+#include <linux/jump_label.h>
+
/* duplicated to the one in bootmem.h */
extern unsigned long max_pfn;
extern unsigned long phys_base;
@@ -43,15 +45,19 @@ static inline unsigned long __phys_addr_nodebug(unsigned long x)
void clear_page_orig(void *page);
void clear_page_rep(void *page);
void clear_page_erms(void *page);
+extern struct static_key_false clear_page_movq_key;
static inline void clear_page(void *page)
{
- alternative_call_2(clear_page_orig,
- clear_page_rep, X86_FEATURE_REP_GOOD,
- clear_page_erms, X86_FEATURE_ERMS,
- "=D" (page),
- "0" (page)
- : "cc", "memory", "rax", "rcx");
+ if (static_branch_unlikely(&clear_page_movq_key))
+ clear_page_orig(page);
+ else
+ alternative_call_2(clear_page_orig,
+ clear_page_rep, X86_FEATURE_REP_GOOD,
+ clear_page_erms, X86_FEATURE_ERMS,
+ "=D" (page),
+ "0" (page)
+ : "cc", "memory", "rax", "rcx");
}
void copy_page(void *to, void *from);
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 8321c43..3366da0 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -38,6 +38,28 @@
#include <asm/apic.h>
#endif
+/* Optimize clear page with movq in specific Intel CPU */
+#include <asm/cpu_device_id.h>
+#include <linux/jump_label.h>
+
+DEFINE_STATIC_KEY_FALSE(clear_page_movq_key);
+EXPORT_SYMBOL_GPL(clear_page_movq_key);
+
+extern const struct x86_cpu_id *x86_match_cpu(const struct x86_cpu_id *match);
+
+const struct x86_cpu_id faststring_blacklist_match[] __initconst = {
+ X86_MATCH_INTEL_FAM6_MODEL(SKYLAKE_X, 0),
+ X86_MATCH_INTEL_FAM6_MODEL(ICELAKE_X, 0),
+ X86_MATCH_INTEL_FAM6_MODEL(ICELAKE_XEON_D, 0)
+};
+
+void enable_clear_page_movq(void)
+{
+ if (x86_match_cpu(faststring_blacklist_match))
+ static_branch_enable(&clear_page_movq_key);
+}
+
+
enum split_lock_detect_state {
sld_off = 0,
sld_warn,
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 23a14d8..480c189 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -28,6 +28,12 @@
#include <asm/memtype.h>
/*
+ * Optimize clear page with movq in specific Intel CPU
+ * Definition in intel.c
+ */
+extern void enable_clear_page_movq(void);
+
+/*
* We need to define the tracepoints somewhere, and tlb.c
* is only compiled when SMP=y.
*/
@@ -775,6 +781,9 @@ void __init init_mem_mapping(void)
x86_init.hyper.init_mem_mapping();
+ /* Optimize clear page with mov in specific Intel CPU */
+ enable_clear_page_movq();
+
early_memtest(0, max_pfn_mapped << PAGE_SHIFT);
}
--
1.8.3.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] perf: optimize clear page in Intel specified model with movq instruction
2021-09-09 8:45 [PATCH] perf: optimize clear page in Intel specified model with movq instruction Jinhua Wu
@ 2021-09-09 9:39 ` Borislav Petkov
2021-09-09 10:34 ` Luming Yu
[not found] ` <bf6fe59d-c760-40d4-8201-4170cd90ffc3.wujinhua@linux.alibaba.com>
0 siblings, 2 replies; 10+ messages in thread
From: Borislav Petkov @ 2021-09-09 9:39 UTC (permalink / raw)
To: Jinhua Wu
Cc: x86, zelin.deng, jiayu.ni, ak, luming.yu, fan.du, artie.ding,
tony.luck, tglx, linux-kernel, pawan.kumar.gupta, fenghua.yu,
hpa, ricardo.neri-calderon, peterz
On Thu, Sep 09, 2021 at 04:45:51PM +0800, Jinhua Wu wrote:
> Clear page is the most time-consuming procedure in page fault handling.
> Kernel use fast-string instruction to clear page. We found that in specified
> Intel model such as CPX and ICX, the movq instruction perform much better
> than fast-string instruction when corresponding page is not in cache.
> But when the page is in cache, fast string perform better. We show the test
> result in the following:
What you should do is show the extensive tests you've run with
real-world benchmarks where you really can show 40% performance
improvement.
Also, the static branch "approach" you're using ain't gonna happen. If
anything, another X86_FEATURE_* bit.
Good luck.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] perf: optimize clear page in Intel specified model with movq instruction
2021-09-09 9:39 ` Borislav Petkov
@ 2021-09-09 10:34 ` Luming Yu
2021-09-09 10:44 ` Borislav Petkov
2021-09-09 11:18 ` Peter Zijlstra
[not found] ` <bf6fe59d-c760-40d4-8201-4170cd90ffc3.wujinhua@linux.alibaba.com>
1 sibling, 2 replies; 10+ messages in thread
From: Luming Yu @ 2021-09-09 10:34 UTC (permalink / raw)
To: Borislav Petkov
Cc: Jinhua Wu, the arch/x86 maintainers, zelin.deng, jiayu.ni,
Andi Kleen, Luming Yu, fan.du, artie.ding, Luck, Tony,
Thomas Gleixner, LKML, pawan.kumar.gupta, Yu, Fenghua,
H. Peter Anvin, ricardo.neri-calderon, Peter Zijlstra
On Thu, Sep 9, 2021 at 5:41 PM Borislav Petkov <bp@alien8.de> wrote:
>
> On Thu, Sep 09, 2021 at 04:45:51PM +0800, Jinhua Wu wrote:
> > Clear page is the most time-consuming procedure in page fault handling.
> > Kernel use fast-string instruction to clear page. We found that in specified
> > Intel model such as CPX and ICX, the movq instruction perform much better
> > than fast-string instruction when corresponding page is not in cache.
> > But when the page is in cache, fast string perform better. We show the test
> > result in the following:
>
> What you should do is show the extensive tests you've run with
> real-world benchmarks where you really can show 40% performance
> improvement.
>
> Also, the static branch "approach" you're using ain't gonna happen. If
> anything, another X86_FEATURE_* bit.
do you mean jump label would not be replaced to nop when its key is enabled?
so we could not use it in certain functions?
I don't understand exactly what "ain't gonna happen"
>
> Good luck.
>
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] perf: optimize clear page in Intel specified model with movq instruction
2021-09-09 10:34 ` Luming Yu
@ 2021-09-09 10:44 ` Borislav Petkov
2021-09-09 11:18 ` Peter Zijlstra
1 sibling, 0 replies; 10+ messages in thread
From: Borislav Petkov @ 2021-09-09 10:44 UTC (permalink / raw)
To: Luming Yu
Cc: Jinhua Wu, the arch/x86 maintainers, zelin.deng, jiayu.ni,
Andi Kleen, Luming Yu, fan.du, artie.ding, Luck, Tony,
Thomas Gleixner, LKML, pawan.kumar.gupta, Yu, Fenghua,
H. Peter Anvin, ricardo.neri-calderon, Peter Zijlstra
On Thu, Sep 09, 2021 at 06:34:40PM +0800, Luming Yu wrote:
> do you mean jump label would not be replaced to nop when its key is enabled?
> so we could not use it in certain functions?
> I don't understand exactly what "ain't gonna happen"
It means, you need to use an X86_FEATURE_ bit because I won't accept a
static key.
But do the benchmarks first.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: 回复:[PATCH] perf: optimize clear page in Intel specified model with movq instruction
[not found] ` <bf6fe59d-c760-40d4-8201-4170cd90ffc3.wujinhua@linux.alibaba.com>
@ 2021-09-09 11:07 ` Borislav Petkov
2021-09-09 14:51 ` Luming Yu
0 siblings, 1 reply; 10+ messages in thread
From: Borislav Petkov @ 2021-09-09 11:07 UTC (permalink / raw)
To: wujinhua
Cc: x86, zelin.deng, jiayu.ni, ak, luming.yu, fan.du, artie.ding,
tony.luck, tglx, linux-kernel, pawan.kumar.gupta, fenghua.yu,
hpa, ricardo.neri-calderon, peterz
On Thu, Sep 09, 2021 at 07:02:08PM +0800, wujinhua wrote:
> I provide three tests and result for you. All the tests run in Intel
> CPX.
I said
"What you should do is show the extensive tests you've run with
real-world benchmarks..."
Are your tests real-world benchmarks?
IOW, no microbenchmarks please.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] perf: optimize clear page in Intel specified model with movq instruction
2021-09-09 10:34 ` Luming Yu
2021-09-09 10:44 ` Borislav Petkov
@ 2021-09-09 11:18 ` Peter Zijlstra
1 sibling, 0 replies; 10+ messages in thread
From: Peter Zijlstra @ 2021-09-09 11:18 UTC (permalink / raw)
To: Luming Yu
Cc: Borislav Petkov, Jinhua Wu, the arch/x86 maintainers, zelin.deng,
jiayu.ni, Andi Kleen, Luming Yu, fan.du, artie.ding, Luck, Tony,
Thomas Gleixner, LKML, pawan.kumar.gupta, Yu, Fenghua,
H. Peter Anvin, ricardo.neri-calderon
On Thu, Sep 09, 2021 at 06:34:40PM +0800, Luming Yu wrote:
> do you mean jump label would not be replaced to nop when its key is enabled?
> so we could not use it in certain functions?
But why add a jump label when you can make that alternative DTRT ?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: 回复:[PATCH] perf: optimize clear page in Intel specified model with movq instruction
2021-09-09 11:07 ` 回复:[PATCH] " Borislav Petkov
@ 2021-09-09 14:51 ` Luming Yu
[not found] ` <1cac1499-6b00-3c18-b64c-a22f269a2706@linux.alibaba.com>
0 siblings, 1 reply; 10+ messages in thread
From: Luming Yu @ 2021-09-09 14:51 UTC (permalink / raw)
To: Borislav Petkov
Cc: wujinhua, x86, zelin.deng, jiayu.ni, ak, luming.yu, fan.du,
artie.ding, tony.luck, tglx, linux-kernel, pawan.kumar.gupta,
fenghua.yu, hpa, ricardo.neri-calderon, peterz
On Thu, Sep 9, 2021 at 7:08 PM Borislav Petkov <bp@alien8.de> wrote:
>
> On Thu, Sep 09, 2021 at 07:02:08PM +0800, wujinhua wrote:
> > I provide three tests and result for you. All the tests run in Intel
> > CPX.
>
> I said
>
> "What you should do is show the extensive tests you've run with
> real-world benchmarks..."
>
> Are your tests real-world benchmarks?
>
> IOW, no microbenchmarks please.
In theory, I thought it should help system boot time , app/dock launch
time as well
as some customer specific marco benchmarks.
>
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: 回复:[PATCH] perf: optimize clear page in Intel specified model with movq instruction
[not found] ` <1cac1499-6b00-3c18-b64c-a22f269a2706@linux.alibaba.com>
@ 2021-10-16 13:22 ` Borislav Petkov
[not found] ` <7b07f141-12f5-397d-9e45-1d507cacae84@linux.alibaba.com>
0 siblings, 1 reply; 10+ messages in thread
From: Borislav Petkov @ 2021-10-16 13:22 UTC (permalink / raw)
To: JY Ni
Cc: Luming Yu, wujinhua, x86, zelin.deng, ak, luming.yu, fan.du,
artie.ding, tony.luck, tglx, linux-kernel, pawan.kumar.gupta,
fenghua.yu, hpa, ricardo.neri-calderon, peterz
On Sat, Oct 16, 2021 at 08:58:32PM +0800, JY Ni wrote:
> I rebased this patch on linux-next repo and measured the time of building a
> same kernel in original/add-movq-patch version on the same intel CPX server.
...
> delta = (*build_original_time* - *build_movq_time*) / (*build_movq_time*)
>
> This set of data shows that movq-patch version has better performance than
> original version in most cases.
First of all, please do not top-post but put your answer under the
quoted text like everyone else.
Then, please explain how exactly you ran that measurement so that I can
try to reproduce it here too.
And just to make sure we're talking about the same thing: the patch in
question is this one:
https://lore.kernel.org/r/1631177151-53723-1-git-send-email-wujinhua@linux.alibaba.com
correct?
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: 回复:[PATCH] perf: optimize clear page in Intel specified model with movq instruction
[not found] ` <7b07f141-12f5-397d-9e45-1d507cacae84@linux.alibaba.com>
@ 2021-10-18 12:43 ` Borislav Petkov
2021-10-18 14:44 ` Luming Yu
0 siblings, 1 reply; 10+ messages in thread
From: Borislav Petkov @ 2021-10-18 12:43 UTC (permalink / raw)
To: JY Ni
Cc: Luming Yu, wujinhua, x86, zelin.deng, ak, luming.yu, fan.du,
artie.ding, tony.luck, tglx, linux-kernel, pawan.kumar.gupta,
fenghua.yu, hpa, ricardo.neri-calderon, peterz
On Mon, Oct 18, 2021 at 03:43:46PM +0800, JY Ni wrote:
> _*Precondition:*__*do tests on a Intel CPX server.*_ CPU information of my
> test machine is in backup part._*
My machine:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 106
stepping : 4
That's a SKYLAKE_X.
I ran
./tools/perf/perf stat --repeat 5 --sync --pre=/root/bin/pre-build-kernel.sh -- make -s -j96 bzImage
on -rc6, building allmodconfig each of the 10 times.
pre-build-kernel.sh is
---
#!/bin/bash
make -s clean
echo 3 > /proc/sys/vm/drop_caches
---
Results are below but to me that's all "in the noise" with around one
percent if I can trust the stddev. Which is not even close to 40%.
So basically you're wasting your time.
5.15-rc6
--------
# ./tools/perf/perf stat --repeat 5 --sync --pre=/root/bin/pre-build-kernel.sh -- make -s -j96 bzImage
Performance counter stats for 'make -s -j96 bzImage' (5 runs):
3,072,392.92 msec task-clock # 51.109 CPUs utilized ( +- 0.05% )
1,351,534 context-switches # 440.257 /sec ( +- 0.99% )
224,862 cpu-migrations # 73.248 /sec ( +- 1.39% )
85,073,723 page-faults # 27.712 K/sec ( +- 0.01% )
8,743,357,421,495 cycles # 2.848 GHz ( +- 0.06% )
7,643,946,991,468 instructions # 0.88 insn per cycle ( +- 0.00% )
1,705,128,638,240 branches # 555.440 M/sec ( +- 0.00% )
37,637,576,027 branch-misses # 2.21% of all branches ( +- 0.03% )
22,511,903,971,150 slots # 7.333 G/sec ( +- 0.03% )
7,377,211,958,188 topdown-retiring # 32.5% retiring ( +- 0.02% )
3,145,247,374,138 topdown-bad-spec # 13.9% bad speculation ( +- 0.27% )
8,018,664,899,041 topdown-fe-bound # 35.2% frontend bound ( +- 0.07% )
4,167,103,609,622 topdown-be-bound # 18.3% backend bound ( +- 0.09% )
60.114 +- 0.112 seconds time elapsed ( +- 0.19% )
5.15-rc6 + patch
----------------
Performance counter stats for 'make -s -j96 bzImage' (5 runs):
3,033,250.65 msec task-clock # 51.243 CPUs utilized ( +- 0.05% )
1,329,033 context-switches # 438.210 /sec ( +- 0.64% )
225,550 cpu-migrations # 74.369 /sec ( +- 1.36% )
85,080,938 page-faults # 28.053 K/sec ( +- 0.00% )
8,629,663,367,477 cycles # 2.845 GHz ( +- 0.05% )
7,696,237,813,803 instructions # 0.89 insn per cycle ( +- 0.00% )
1,709,909,494,107 branches # 563.793 M/sec ( +- 0.00% )
37,719,552,337 branch-misses # 2.21% of all branches ( +- 0.02% )
22,214,249,023,820 slots # 7.325 G/sec ( +- 0.06% )
7,412,342,725,008 topdown-retiring # 33.0% retiring ( +- 0.01% )
3,141,090,408,028 topdown-bad-spec # 14.1% bad speculation ( +- 0.17% )
7,996,077,873,517 topdown-fe-bound # 35.6% frontend bound ( +- 0.03% )
3,862,154,886,962 topdown-be-bound # 17.3% backend bound ( +- 0.28% )
59.193 +- 0.302 seconds time elapsed ( +- 0.51% )
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: 回复:[PATCH] perf: optimize clear page in Intel specified model with movq instruction
2021-10-18 12:43 ` Borislav Petkov
@ 2021-10-18 14:44 ` Luming Yu
0 siblings, 0 replies; 10+ messages in thread
From: Luming Yu @ 2021-10-18 14:44 UTC (permalink / raw)
To: Borislav Petkov
Cc: JY Ni, wujinhua, x86, zelin.deng, ak, luming.yu, fan.du,
artie.ding, tony.luck, tglx, linux-kernel, pawan.kumar.gupta,
fenghua.yu, hpa, ricardo.neri-calderon, peterz
On Mon, Oct 18, 2021 at 8:43 PM Borislav Petkov <bp@alien8.de> wrote:
>
> On Mon, Oct 18, 2021 at 03:43:46PM +0800, JY Ni wrote:
> > _*Precondition:*__*do tests on a Intel CPX server.*_ CPU information of my
> > test machine is in backup part._*
>
> My machine:
>
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 6
> model : 106
> stepping : 4
>
> That's a SKYLAKE_X.
>
> I ran
>
> ./tools/perf/perf stat --repeat 5 --sync --pre=/root/bin/pre-build-kernel.sh -- make -s -j96 bzImage
>
> on -rc6, building allmodconfig each of the 10 times.
>
> pre-build-kernel.sh is
>
> ---
> #!/bin/bash
>
> make -s clean
> echo 3 > /proc/sys/vm/drop_caches
> ---
>
> Results are below but to me that's all "in the noise" with around one
> percent if I can trust the stddev. Which is not even close to 40%.
>
> So basically you're wasting your time.
>
> 5.15-rc6
> --------
>
> # ./tools/perf/perf stat --repeat 5 --sync --pre=/root/bin/pre-build-kernel.sh -- make -s -j96 bzImage
>
> Performance counter stats for 'make -s -j96 bzImage' (5 runs):
>
> 3,072,392.92 msec task-clock # 51.109 CPUs utilized ( +- 0.05% )
> 1,351,534 context-switches # 440.257 /sec ( +- 0.99% )
> 224,862 cpu-migrations # 73.248 /sec ( +- 1.39% )
> 85,073,723 page-faults # 27.712 K/sec ( +- 0.01% )
> 8,743,357,421,495 cycles # 2.848 GHz ( +- 0.06% )
> 7,643,946,991,468 instructions # 0.88 insn per cycle ( +- 0.00% )
> 1,705,128,638,240 branches # 555.440 M/sec ( +- 0.00% )
> 37,637,576,027 branch-misses # 2.21% of all branches ( +- 0.03% )
> 22,511,903,971,150 slots # 7.333 G/sec ( +- 0.03% )
> 7,377,211,958,188 topdown-retiring # 32.5% retiring ( +- 0.02% )
> 3,145,247,374,138 topdown-bad-spec # 13.9% bad speculation ( +- 0.27% )
> 8,018,664,899,041 topdown-fe-bound # 35.2% frontend bound ( +- 0.07% )
> 4,167,103,609,622 topdown-be-bound # 18.3% backend bound ( +- 0.09% )
>
> 60.114 +- 0.112 seconds time elapsed ( +- 0.19% )
>
>
>
> 5.15-rc6 + patch
> ----------------
>
> Performance counter stats for 'make -s -j96 bzImage' (5 runs):
>
> 3,033,250.65 msec task-clock # 51.243 CPUs utilized ( +- 0.05% )
> 1,329,033 context-switches # 438.210 /sec ( +- 0.64% )
> 225,550 cpu-migrations # 74.369 /sec ( +- 1.36% )
> 85,080,938 page-faults # 28.053 K/sec ( +- 0.00% )
> 8,629,663,367,477 cycles # 2.845 GHz ( +- 0.05% )
> 7,696,237,813,803 instructions # 0.89 insn per cycle ( +- 0.00% )
> 1,709,909,494,107 branches # 563.793 M/sec ( +- 0.00% )
> 37,719,552,337 branch-misses # 2.21% of all branches ( +- 0.02% )
> 22,214,249,023,820 slots # 7.325 G/sec ( +- 0.06% )
> 7,412,342,725,008 topdown-retiring # 33.0% retiring ( +- 0.01% )
> 3,141,090,408,028 topdown-bad-spec # 14.1% bad speculation ( +- 0.17% )
> 7,996,077,873,517 topdown-fe-bound # 35.6% frontend bound ( +- 0.03% )
> 3,862,154,886,962 topdown-be-bound # 17.3% backend bound ( +- 0.28% )
>
> 59.193 +- 0.302 seconds time elapsed ( +- 0.51% )
I'm trying to duplicate the difference and get noticed that time && perf stat
might have a different scale view about the real time spent on the job.
And jiayu.ni's time diff showed the best at 32 jobs and the worst at 96 jobs.
[linux-5.15-rc6]# time make -s bzImage -j96
real 1m8.922s
user 55m25.750s
sys 7m30.666s
[linux-5.15-rc6]# make -s clean
[linux-5.15-rc6]# perf stat make -s bzImage -j96
..
61.461679693 seconds time elapsed
2756.927852000 seconds user
369.365209000 seconds sys
If kbuild time that jiayu.ni has shared is not a solid proof for the
optimization idea can be accepted,
we can try other clear_page heavy workloads.
>
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2021-10-18 14:44 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-09 8:45 [PATCH] perf: optimize clear page in Intel specified model with movq instruction Jinhua Wu
2021-09-09 9:39 ` Borislav Petkov
2021-09-09 10:34 ` Luming Yu
2021-09-09 10:44 ` Borislav Petkov
2021-09-09 11:18 ` Peter Zijlstra
[not found] ` <bf6fe59d-c760-40d4-8201-4170cd90ffc3.wujinhua@linux.alibaba.com>
2021-09-09 11:07 ` 回复:[PATCH] " Borislav Petkov
2021-09-09 14:51 ` Luming Yu
[not found] ` <1cac1499-6b00-3c18-b64c-a22f269a2706@linux.alibaba.com>
2021-10-16 13:22 ` Borislav Petkov
[not found] ` <7b07f141-12f5-397d-9e45-1d507cacae84@linux.alibaba.com>
2021-10-18 12:43 ` Borislav Petkov
2021-10-18 14:44 ` Luming Yu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).