* Re: [PATCH] ACPI: PPTT: Fix processor subtable walk
2025-05-08 2:30 [PATCH] ACPI: PPTT: Fix processor subtable walk Jeremy Linton
@ 2025-05-08 4:00 ` Yicong Yang
2025-05-08 9:12 ` Sudeep Holla
` (2 subsequent siblings)
3 siblings, 0 replies; 6+ messages in thread
From: Yicong Yang @ 2025-05-08 4:00 UTC (permalink / raw)
To: Jeremy Linton, rafael
Cc: yangyicong, lenb, jmeurin, linux-acpi, linux-kernel, sudeep.holla,
Maximilian Heyne, stable
On 2025/5/8 10:30, Jeremy Linton wrote:
> The original PPTT code had a bug where the processor subtable length
> was not correctly validated when encountering a truncated
> acpi_pptt_processor node.
>
> Commit 7ab4f0e37a0f4 ("ACPI PPTT: Fix coding mistakes in a couple of
> sizeof() calls") attempted to fix this by validating the size is as
> large as the acpi_pptt_processor node structure. This introduced a
> regression where the last processor node in the PPTT table is ignored
> if it doesn't contain any private resources. That results errors like:
>
> ACPI PPTT: PPTT table found, but unable to locate core XX (XX)
> ACPI: SPE must be homogeneous
>
> Furthermore, it fail in a common case where the node length isn't
> equal to the acpi_pptt_processor structure size, leaving the original
> bug in a modified form.
>
> Correct the regression by adjusting the loop termination conditions as
> suggested by the bug reporters. An additional check performed after
> the subtable node type is detected, validates the acpi_pptt_processor
> node is fully contained in the PPTT table. Repeating the check in
> acpi_pptt_leaf_node() is largely redundant as the node is already
> known to be fully contained in the table.
>
> The case where a final truncated node's parent property is accepted,
> but the node itself is rejected should not be considered a bug.
>
> Fixes: 7ab4f0e37a0f4 ("ACPI PPTT: Fix coding mistakes in a couple of sizeof() calls")
> Reported-by: Maximilian Heyne <mheyne@amazon.de>
> Closes: https://lore.kernel.org/linux-acpi/20250506-draco-taped-15f475cd@mheyne-amazon/
> Reported-by: Yicong Yang <yangyicong@hisilicon.com>
Thanks for the fix. The last CPU in the PPTT can be parsed on my board with this.
Tested-by: Yicong Yang <yangyicong@hisilicon.com>
> Closes: https://lore.kernel.org/linux-acpi/20250507035124.28071-1-yangyicong@huawei.com/
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> Cc: Jean-Marc Eurin <jmeurin@google.com>
> Cc: <stable@vger.kernel.org>
> ---
> drivers/acpi/pptt.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
> index f73ce6e13065..54676e3d82dd 100644
> --- a/drivers/acpi/pptt.c
> +++ b/drivers/acpi/pptt.c
> @@ -231,16 +231,18 @@ static int acpi_pptt_leaf_node(struct acpi_table_header *table_hdr,
> sizeof(struct acpi_table_pptt));
> proc_sz = sizeof(struct acpi_pptt_processor);
>
> - while ((unsigned long)entry + proc_sz < table_end) {
> + /* ignore subtable types that are smaller than a processor node */
> + while ((unsigned long)entry + proc_sz <= table_end) {
> cpu_node = (struct acpi_pptt_processor *)entry;
> +
> if (entry->type == ACPI_PPTT_TYPE_PROCESSOR &&
> cpu_node->parent == node_entry)
> return 0;
> if (entry->length == 0)
> return 0;
> +
> entry = ACPI_ADD_PTR(struct acpi_subtable_header, entry,
> entry->length);
> -
> }
> return 1;
> }
> @@ -273,15 +275,18 @@ static struct acpi_pptt_processor *acpi_find_processor_node(struct acpi_table_he
> proc_sz = sizeof(struct acpi_pptt_processor);
>
> /* find the processor structure associated with this cpuid */
> - while ((unsigned long)entry + proc_sz < table_end) {
> + while ((unsigned long)entry + proc_sz <= table_end) {
> cpu_node = (struct acpi_pptt_processor *)entry;
>
> if (entry->length == 0) {
> pr_warn("Invalid zero length subtable\n");
> break;
> }
> + /* entry->length may not equal proc_sz, revalidate the processor structure length */
> if (entry->type == ACPI_PPTT_TYPE_PROCESSOR &&
> acpi_cpu_id == cpu_node->acpi_processor_id &&
> + (unsigned long)entry + entry->length <= table_end &&
> + entry->length == proc_sz + cpu_node->number_of_priv_resources * sizeof(u32) &&
> acpi_pptt_leaf_node(table_hdr, cpu_node)) {
> return (struct acpi_pptt_processor *)entry;
> }
>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] ACPI: PPTT: Fix processor subtable walk
2025-05-08 2:30 [PATCH] ACPI: PPTT: Fix processor subtable walk Jeremy Linton
2025-05-08 4:00 ` Yicong Yang
@ 2025-05-08 9:12 ` Sudeep Holla
2025-05-08 18:26 ` Rafael J. Wysocki
2025-05-08 14:50 ` Heyne, Maximilian
2025-05-14 13:07 ` Aishwarya
3 siblings, 1 reply; 6+ messages in thread
From: Sudeep Holla @ 2025-05-08 9:12 UTC (permalink / raw)
To: Jeremy Linton
Cc: rafael, lenb, jmeurin, linux-acpi, linux-kernel, Maximilian Heyne,
Sudeep Holla, Yicong Yang, stable
On Wed, May 07, 2025 at 09:30:25PM -0500, Jeremy Linton wrote:
> The original PPTT code had a bug where the processor subtable length
> was not correctly validated when encountering a truncated
> acpi_pptt_processor node.
>
> Commit 7ab4f0e37a0f4 ("ACPI PPTT: Fix coding mistakes in a couple of
> sizeof() calls") attempted to fix this by validating the size is as
> large as the acpi_pptt_processor node structure. This introduced a
> regression where the last processor node in the PPTT table is ignored
> if it doesn't contain any private resources. That results errors like:
>
> ACPI PPTT: PPTT table found, but unable to locate core XX (XX)
> ACPI: SPE must be homogeneous
>
> Furthermore, it fail in a common case where the node length isn't
> equal to the acpi_pptt_processor structure size, leaving the original
> bug in a modified form.
>
> Correct the regression by adjusting the loop termination conditions as
> suggested by the bug reporters. An additional check performed after
> the subtable node type is detected, validates the acpi_pptt_processor
> node is fully contained in the PPTT table. Repeating the check in
> acpi_pptt_leaf_node() is largely redundant as the node is already
> known to be fully contained in the table.
>
> The case where a final truncated node's parent property is accepted,
> but the node itself is rejected should not be considered a bug.
>
Thanks for picking this up and describing the issue properly in the commit
message.
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] ACPI: PPTT: Fix processor subtable walk
2025-05-08 9:12 ` Sudeep Holla
@ 2025-05-08 18:26 ` Rafael J. Wysocki
0 siblings, 0 replies; 6+ messages in thread
From: Rafael J. Wysocki @ 2025-05-08 18:26 UTC (permalink / raw)
To: Sudeep Holla
Cc: Jeremy Linton, rafael, lenb, jmeurin, linux-acpi, linux-kernel,
Maximilian Heyne, Yicong Yang, stable
On Thu, May 8, 2025 at 11:13 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> On Wed, May 07, 2025 at 09:30:25PM -0500, Jeremy Linton wrote:
> > The original PPTT code had a bug where the processor subtable length
> > was not correctly validated when encountering a truncated
> > acpi_pptt_processor node.
> >
> > Commit 7ab4f0e37a0f4 ("ACPI PPTT: Fix coding mistakes in a couple of
> > sizeof() calls") attempted to fix this by validating the size is as
> > large as the acpi_pptt_processor node structure. This introduced a
> > regression where the last processor node in the PPTT table is ignored
> > if it doesn't contain any private resources. That results errors like:
> >
> > ACPI PPTT: PPTT table found, but unable to locate core XX (XX)
> > ACPI: SPE must be homogeneous
> >
> > Furthermore, it fail in a common case where the node length isn't
> > equal to the acpi_pptt_processor structure size, leaving the original
> > bug in a modified form.
> >
> > Correct the regression by adjusting the loop termination conditions as
> > suggested by the bug reporters. An additional check performed after
> > the subtable node type is detected, validates the acpi_pptt_processor
> > node is fully contained in the PPTT table. Repeating the check in
> > acpi_pptt_leaf_node() is largely redundant as the node is already
> > known to be fully contained in the table.
> >
> > The case where a final truncated node's parent property is accepted,
> > but the node itself is rejected should not be considered a bug.
> >
>
> Thanks for picking this up and describing the issue properly in the commit
> message.
>
> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Applied, but it is a bit too late to push it for -rc6, so I'll queue
it up for -rc7.
Thanks!
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ACPI: PPTT: Fix processor subtable walk
2025-05-08 2:30 [PATCH] ACPI: PPTT: Fix processor subtable walk Jeremy Linton
2025-05-08 4:00 ` Yicong Yang
2025-05-08 9:12 ` Sudeep Holla
@ 2025-05-08 14:50 ` Heyne, Maximilian
2025-05-14 13:07 ` Aishwarya
3 siblings, 0 replies; 6+ messages in thread
From: Heyne, Maximilian @ 2025-05-08 14:50 UTC (permalink / raw)
To: Jeremy Linton
Cc: rafael@kernel.org, lenb@kernel.org, jmeurin@google.com,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
sudeep.holla@arm.com, Yicong Yang, stable@vger.kernel.org
On Wed, May 07, 2025 at 09:30:25PM -0500, Jeremy Linton wrote:
> The original PPTT code had a bug where the processor subtable length
> was not correctly validated when encountering a truncated
> acpi_pptt_processor node.
>
> Commit 7ab4f0e37a0f4 ("ACPI PPTT: Fix coding mistakes in a couple of
> sizeof() calls") attempted to fix this by validating the size is as
> large as the acpi_pptt_processor node structure. This introduced a
> regression where the last processor node in the PPTT table is ignored
> if it doesn't contain any private resources. That results errors like:
>
> ACPI PPTT: PPTT table found, but unable to locate core XX (XX)
> ACPI: SPE must be homogeneous
>
> Furthermore, it fail in a common case where the node length isn't
> equal to the acpi_pptt_processor structure size, leaving the original
> bug in a modified form.
>
> Correct the regression by adjusting the loop termination conditions as
> suggested by the bug reporters. An additional check performed after
> the subtable node type is detected, validates the acpi_pptt_processor
> node is fully contained in the PPTT table. Repeating the check in
> acpi_pptt_leaf_node() is largely redundant as the node is already
> known to be fully contained in the table.
>
> The case where a final truncated node's parent property is accepted,
> but the node itself is rejected should not be considered a bug.
>
> Fixes: 7ab4f0e37a0f4 ("ACPI PPTT: Fix coding mistakes in a couple of sizeof() calls")
> Reported-by: Maximilian Heyne <mheyne@amazon.de>
> Closes: https://lore.kernel.org/linux-acpi/20250506-draco-taped-15f475cd@mheyne-amazon/
> Reported-by: Yicong Yang <yangyicong@hisilicon.com>
> Closes: https://lore.kernel.org/linux-acpi/20250507035124.28071-1-yangyicong@huawei.com/
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> Cc: Jean-Marc Eurin <jmeurin@google.com>
> Cc: <stable@vger.kernel.org>
Thank you so much for providing this proper fix and also thanks for the
great discussions. This allowed my to learn new things. Much
appreciated.
I confirm the fix works for me. Therefore,
Tested-by: Maximilian Heyne <mheyne@amazon.de>
Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] ACPI: PPTT: Fix processor subtable walk
2025-05-08 2:30 [PATCH] ACPI: PPTT: Fix processor subtable walk Jeremy Linton
` (2 preceding siblings ...)
2025-05-08 14:50 ` Heyne, Maximilian
@ 2025-05-14 13:07 ` Aishwarya
3 siblings, 0 replies; 6+ messages in thread
From: Aishwarya @ 2025-05-14 13:07 UTC (permalink / raw)
To: jeremy.linton
Cc: jmeurin, lenb, linux-acpi, linux-kernel, mheyne, rafael, stable,
sudeep.holla, yangyicong, ryan.roberts
Hi Jeremy,
Thanks for providing this fix. We've tested applying the patch on top
of v6.15-rc6 and would like to confirm that commit
7ab4f0e37a0f4207e742a8de69be03984db6ebf0
was indeed the root cause of a severe performance regression observed
on Graviton3 bare-metal systems during the 6.15 development cycle.
After applying the patch, all regressions were fully resolved.
The degradation began in v6.15-rc2 and persisted through rc6. Through
bisection, we identified the above commit as introducing incorrect
handling in ACPI PPTT parsing. This likely caused malformed CPU
topology and broken scheduling domains.
As further evidence, we observed the following warning in the kernel
logs during affected runs. This was with: Linux version 6.15.0-rc6
[ 0.511191] ------------[ cut here ]------------
[ 0.511193] WARNING: CPU: 0 PID: 1 at kernel/sched/topology.c:2411 build_sched_domains+0x674/0x1204
[ 0.511201] Modules linked in:
[ 0.511205] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G S 6.15.0-rc6 #1 PREEMPT
[ 0.511209] Tainted: [S]=CPU_OUT_OF_SPEC
[ 0.511211] pstate: 01400009 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[ 0.511214] pc : build_sched_domains+0x674/0x1204
[ 0.511217] lr : build_sched_domains+0x354/0x1204
[ 0.511220] sp : ffff80008021bce0
[ 0.511222] x29: ffff80008021bd60 x28: ffff00010253e300 x27: ffff000100b74440
[ 0.511226] x26: ffffdd63645167f8 x25: ffffdd636373aee8 x24: 0000000000001297
[ 0.511229] x23: ffffdd6364aa4518 x22: 000000000000003f x21: 0000000000000000
[ 0.511233] x20: ffffdd63644fb030 x19: ffff0001014e9270 x18: ffffffffff435f00
[ 0.511236] x17: 4d52415120646574 x16: 6365746968637261 x15: 0000000000000001
[ 0.511239] x14: 0000000000000000 x13: 0000000000000318 x12: 0000000000002000
[ 0.511243] x11: ffff00815ff0e154 x10: ffffdd6364aa4518 x9 : ffffdd6364aa4510
[ 0.511246] x8 : ffffdd6364aa8780 x7 : 0000000000000002 x6 : 7fffffffffffffff
[ 0.511249] x5 : ffffffffffffffff x4 : 0000000000000002 x3 : 0000000000000001
[ 0.511252] x2 : 0000000000000040 x1 : ffffdd6364aa8788 x0 : 0000000000000001
[ 0.511256] Call trace:
[ 0.511258] build_sched_domains+0x674/0x1204 (P)
[ 0.511262] sched_init_domains+0xc8/0x104
[ 0.511267] sched_init_smp+0x40/0xc0
[ 0.511270] kernel_init_freeable+0x100/0x28c
[ 0.511273] kernel_init+0x20/0x1d8
[ 0.511277] ret_from_fork+0x10/0x20
[ 0.511281] ---[ end trace 0000000000000000 ]---
Based on this, we believe the truncation of the PPTT was confusing the
scheduler about the system's CPU topology. This likely explains the
observed regressions.
Example impact (`pts/pgbench` with 100 clients / 1000 scale):
- TPS dropped by up to -98.8%
- Latency increased by over +8200%
Other workloads affected:
- mmtests/sysbench-thread showed ~+600% increase in latency
- mmtests/stressng-* (get, wait, vm-splice) regressed by -90%+
- pts/memtier and nginx throughput dropped by ~98%
We’ve shared the full benchmark results in the thread below to support
these findings.
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| Benchmark | Result Class | 6-14-0 (base) | 6-15-0-rc5 | 6-15-0-rc6-g28a90db81645 |
+====================================+==========================================================+=================+==============+============================+
| micromm/fork | fork: p:1, d:10 (seconds) | 0.00% | (R) 24.31% | 0.93% |
| | fork: p:512, d:10 (seconds) | 0.00% | (R) 5.45% | -1.39% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| micromm/munmap | munmap: p:1, d:10 (seconds) | 0.00% | -0.04% | 0.70% |
| | munmap: p:512, d:10 (seconds) | 0.00% | (R) 3.75% | (R) 2.93% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| micromm/vmalloc | fix_align_alloc_test: p:1, h:0, l:500000 (usec) | 0.00% | 0.34% | (R) 5.04% |
| | fix_size_alloc_test: p:1, h:0, l:500000 (usec) | 0.00% | -1.61% | -0.93% |
| | fix_size_alloc_test: p:4, h:0, l:500000 (usec) | 0.00% | 0.59% | (R) 3.98% |
| | fix_size_alloc_test: p:16, h:0, l:500000 (usec) | 0.00% | 3.96% | (R) 7.79% |
| | fix_size_alloc_test: p:16, h:1, l:500000 (usec) | 0.00% | (R) 2.14% | (R) 7.48% |
| | fix_size_alloc_test: p:64, h:0, l:100000 (usec) | 0.00% | (R) 3.50% | (R) 8.80% |
| | fix_size_alloc_test: p:64, h:1, l:100000 (usec) | 0.00% | (R) 3.30% | (R) 8.76% |
| | fix_size_alloc_test: p:256, h:0, l:100000 (usec) | 0.00% | (R) 3.86% | (R) 9.65% |
| | fix_size_alloc_test: p:256, h:1, l:100000 (usec) | 0.00% | (R) 3.44% | (R) 9.68% |
| | fix_size_alloc_test: p:512, h:0, l:100000 (usec) | 0.00% | (R) 3.37% | (R) 9.75% |
| | fix_size_alloc_test: p:512, h:1, l:100000 (usec) | 0.00% | (R) 9.26% | (R) 17.75% |
| | full_fit_alloc_test: p:1, h:0, l:500000 (usec) | 0.00% | (I) -6.70% | 0.37% |
| | kvfree_rcu_1_arg_vmalloc_test: p:1, h:0, l:500000 (usec) | 0.00% | (R) 34.28% | 0.02% |
| | kvfree_rcu_2_arg_vmalloc_test: p:1, h:0, l:500000 (usec) | 0.00% | (R) 35.93% | 0.42% |
| | long_busy_list_alloc_test: p:1, h:0, l:500000 (usec) | 0.00% | 1.63% | (R) 2.36% |
| | pcpu_alloc_test: p:1, h:0, l:500000 (usec) | 0.00% | 2.09% | -1.19% |
| | random_size_align_alloc_test: p:1, h:0, l:500000 (usec) | 0.00% | -1.28% | 1.91% |
| | random_size_alloc_test: p:1, h:0, l:500000 (usec) | 0.00% | (R) 2.93% | (R) 8.94% |
| | vm_map_ram_test: p:1, h:0, l:500000 (usec) | 0.00% | -1.86% | 0.12% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| mmtests/hackbench | process-pipes-1 (seconds) | 0.00% | | (I) -7.13% |
| | process-pipes-4 (seconds) | 0.00% | | (I) -5.44% |
| | process-pipes-7 (seconds) | 0.00% | | (I) -6.24% |
| | process-pipes-12 (seconds) | 0.00% | | (I) -3.90% |
| | process-pipes-21 (seconds) | 0.00% | | (I) -8.26% |
| | process-pipes-30 (seconds) | 0.00% | | (I) -8.50% |
| | process-pipes-48 (seconds) | 0.00% | | (I) -10.24% |
| | process-pipes-79 (seconds) | 0.00% | | (I) -11.82% |
| | process-pipes-110 (seconds) | 0.00% | | (I) -13.15% |
| | process-pipes-141 (seconds) | 0.00% | | (I) -12.25% |
| | process-pipes-172 (seconds) | 0.00% | | (I) -12.79% |
| | process-pipes-203 (seconds) | 0.00% | | (I) -12.86% |
| | process-pipes-234 (seconds) | 0.00% | | (I) -12.98% |
| | process-pipes-256 (seconds) | 0.00% | | (I) -13.12% |
| | process-sockets-1 (seconds) | 0.00% | | 0.11% |
| | process-sockets-4 (seconds) | 0.00% | | -0.22% |
| | process-sockets-7 (seconds) | 0.00% | | 0.61% |
| | process-sockets-12 (seconds) | 0.00% | | -0.02% |
| | process-sockets-21 (seconds) | 0.00% | | 0.57% |
| | process-sockets-30 (seconds) | 0.00% | | -0.10% |
| | process-sockets-48 (seconds) | 0.00% | | -0.63% |
| | process-sockets-79 (seconds) | 0.00% | | 0.14% |
| | process-sockets-110 (seconds) | 0.00% | | 0.43% |
| | process-sockets-141 (seconds) | 0.00% | | 0.64% |
| | process-sockets-172 (seconds) | 0.00% | | 1.04% |
| | process-sockets-203 (seconds) | 0.00% | | -0.11% |
| | process-sockets-234 (seconds) | 0.00% | | 0.31% |
| | process-sockets-256 (seconds) | 0.00% | | 0.60% |
| | thread-pipes-1 (seconds) | 0.00% | | (I) -11.54% |
| | thread-pipes-4 (seconds) | 0.00% | | (I) -8.52% |
| | thread-pipes-7 (seconds) | 0.00% | | (I) -9.90% |
| | thread-pipes-12 (seconds) | 0.00% | | (I) -6.03% |
| | thread-pipes-21 (seconds) | 0.00% | | (I) -8.68% |
| | thread-pipes-30 (seconds) | 0.00% | | (I) -9.16% |
| | thread-pipes-48 (seconds) | 0.00% | | (I) -10.58% |
| | thread-pipes-79 (seconds) | 0.00% | | (I) -14.23% |
| | thread-pipes-110 (seconds) | 0.00% | | (I) -15.06% |
| | thread-pipes-141 (seconds) | 0.00% | | (I) -14.22% |
| | thread-pipes-172 (seconds) | 0.00% | | (I) -14.20% |
| | thread-pipes-203 (seconds) | 0.00% | | (I) -13.78% |
| | thread-pipes-234 (seconds) | 0.00% | | (I) -13.84% |
| | thread-pipes-256 (seconds) | 0.00% | | (I) -13.80% |
| | thread-sockets-1 (seconds) | 0.00% | | (I) -3.70% |
| | thread-sockets-4 (seconds) | 0.00% | | (I) -2.95% |
| | thread-sockets-7 (seconds) | 0.00% | | (I) -2.81% |
| | thread-sockets-12 (seconds) | 0.00% | | (I) -2.31% |
| | thread-sockets-21 (seconds) | 0.00% | | (I) -2.33% |
| | thread-sockets-30 (seconds) | 0.00% | | -1.65% |
| | thread-sockets-48 (seconds) | 0.00% | | -0.93% |
| | thread-sockets-79 (seconds) | 0.00% | | -1.72% |
| | thread-sockets-110 (seconds) | 0.00% | | 0.58% |
| | thread-sockets-141 (seconds) | 0.00% | | 0.02% |
| | thread-sockets-172 (seconds) | 0.00% | | 0.51% |
| | thread-sockets-203 (seconds) | 0.00% | | 0.69% |
| | thread-sockets-234 (seconds) | 0.00% | | 0.50% |
| | thread-sockets-256 (seconds) | 0.00% | | 0.30% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| mmtests/kernbench | elsp-64 (seconds) | 0.00% | | 0.01% |
| | syst-64 (seconds) | 0.00% | | -0.99% |
| | user-64 (seconds) | 0.00% | | -0.10% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| mmtests/stressng-af-alg | 1 (ops/second) | 0.00% | (I) 3.53% | 0.55% |
| | 2 (ops/second) | 0.00% | (R) -47.63% | 0.51% |
| | 4 (ops/second) | 0.00% | (R) -73.57% | 0.54% |
| | 8 (ops/second) | 0.00% | (R) -86.14% | 0.54% |
| | 16 (ops/second) | 0.00% | (R) -92.06% | 1.05% |
| | 32 (ops/second) | 0.00% | (R) -92.38% | 0.29% |
| | 64 (ops/second) | 0.00% | (R) -91.09% | 0.27% |
| | 128 (ops/second) | 0.00% | (R) -90.91% | 0.09% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| mmtests/stressng-bad-altstack | 1 (ops/second) | 0.00% | -0.11% | -0.01% |
| | 2 (ops/second) | 0.00% | (R) -50.95% | -0.00% |
| | 4 (ops/second) | 0.00% | (R) -75.64% | -0.04% |
| | 8 (ops/second) | 0.00% | (R) -85.42% | 1.59% |
| | 16 (ops/second) | 0.00% | (R) -97.55% | (I) 3.31% |
| | 32 (ops/second) | 0.00% | (R) -99.24% | 0.45% |
| | 64 (ops/second) | 0.00% | (R) -99.60% | 0.00% |
| | 128 (ops/second) | 0.00% | (R) -99.62% | 0.40% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| mmtests/stressng-class-io-parallel | stressng-aio-64 (ops/second) | 0.00% | (I) 528.81% | -3.26% |
| | stressng-hdd-64 (ops/second) | 0.00% | (R) -18.32% | -0.60% |
| | stressng-io-uring-64 (ops/second) | 0.00% | (I) 434.84% | 0.96% |
| | stressng-readahead-64 (ops/second) | 0.00% | (R) -98.97% | -1.17% |
| | stressng-revio-64 (ops/second) | 0.00% | (R) -98.92% | -13.03% |
| | stressng-seek-64 (ops/second) | 0.00% | (R) -99.90% | -7.53% |
| | stressng-sync-file-64 (ops/second) | 0.00% | -38.12% | 76.58% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| mmtests/stressng-context | 1 (ops/second) | 0.00% | (R) -3.02% | -1.29% |
| | 2 (ops/second) | 0.00% | (R) -51.93% | -0.98% |
| | 4 (ops/second) | 0.00% | (R) -76.75% | -1.19% |
| | 8 (ops/second) | 0.00% | (R) -88.43% | -1.11% |
| | 16 (ops/second) | 0.00% | (R) -94.03% | -1.07% |
| | 32 (ops/second) | 0.00% | (R) -97.01% | -1.05% |
| | 64 (ops/second) | 0.00% | (R) -98.50% | -1.20% |
| | 128 (ops/second) | 0.00% | (R) -98.51% | -1.06% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| mmtests/stressng-fork | 1 (ops/second) | 0.00% | (I) 12.21% | 4.11% |
| | 2 (ops/second) | 0.00% | (R) -46.26% | 4.75% |
| | 4 (ops/second) | 0.00% | (R) -72.79% | 2.21% |
| | 8 (ops/second) | 0.00% | (R) -85.88% | (I) 3.68% |
| | 16 (ops/second) | 0.00% | (R) -92.30% | (I) 2.55% |
| | 32 (ops/second) | 0.00% | (R) -94.87% | -0.15% |
| | 64 (ops/second) | 0.00% | (R) -95.43% | -6.86% |
| | 128 (ops/second) | 0.00% | (R) -95.79% | -2.29% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| mmtests/stressng-get | 1 (ops/second) | 0.00% | -0.01% | 0.56% |
| | 2 (ops/second) | 0.00% | (R) -46.80% | 0.33% |
| | 4 (ops/second) | 0.00% | (R) -72.05% | 1.63% |
| | 8 (ops/second) | 0.00% | (R) -84.66% | (I) 2.15% |
| | 16 (ops/second) | 0.00% | (R) -88.22% | 1.19% |
| | 32 (ops/second) | 0.00% | (R) -88.21% | 0.92% |
| | 64 (ops/second) | 0.00% | (R) -88.16% | 0.44% |
| | 128 (ops/second) | 0.00% | (R) -87.29% | 1.39% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| mmtests/stressng-getdent | 1 (ops/second) | 0.00% | (R) -4.47% | 0.67% |
| | 2 (ops/second) | 0.00% | (R) -42.27% | 2.01% |
| | 4 (ops/second) | 0.00% | (R) -54.38% | 0.97% |
| | 8 (ops/second) | 0.00% | (R) -57.53% | 1.78% |
| | 16 (ops/second) | 0.00% | (R) -58.90% | 1.98% |
| | 32 (ops/second) | 0.00% | (R) -64.26% | (I) 2.38% |
| | 64 (ops/second) | 0.00% | (R) -65.32% | (I) 3.37% |
| | 128 (ops/second) | 0.00% | (R) -36.72% | -0.36% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| mmtests/stressng-madvise | 1 (ops/second) | 0.00% | | |
| | 2 (ops/second) | 0.00% | (I) 56.22% | 0.13% |
| | 4 (ops/second) | 0.00% | (R) -46.94% | (R) -2.09% |
| | 8 (ops/second) | 0.00% | (R) -76.56% | -1.12% |
| | 16 (ops/second) | 0.00% | (R) -84.55% | -0.55% |
| | 32 (ops/second) | 0.00% | (R) -90.29% | -0.76% |
| | 64 (ops/second) | 0.00% | (R) -90.98% | -1.49% |
| | 128 (ops/second) | 0.00% | (R) -92.53% | -4.13% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| mmtests/stressng-mmap | 1 (ops/second) | 0.00% | (I) 2.70% | (I) 3.60% |
| | 2 (ops/second) | 0.00% | (R) -46.86% | (I) 4.02% |
| | 4 (ops/second) | 0.00% | (R) -71.48% | (I) 4.05% |
| | 8 (ops/second) | 0.00% | (R) -84.90% | (I) 4.67% |
| | 16 (ops/second) | 0.00% | (R) -91.47% | (I) 3.88% |
| | 32 (ops/second) | 0.00% | (R) -92.87% | 1.35% |
| | 64 (ops/second) | 0.00% | (R) -92.04% | 0.81% |
| | 128 (ops/second) | 0.00% | (R) -92.36% | 1.03% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| mmtests/stressng-vm-splice | 1 (ops/second) | 0.00% | (I) 4.43% | (I) 2.93% |
| | 2 (ops/second) | 0.00% | (R) -49.04% | (I) 3.53% |
| | 4 (ops/second) | 0.00% | (R) -74.48% | (I) 3.94% |
| | 8 (ops/second) | 0.00% | (R) -88.44% | (I) 4.39% |
| | 16 (ops/second) | 0.00% | (R) -94.20% | (I) 4.84% |
| | 32 (ops/second) | 0.00% | (R) -96.99% | (I) 5.05% |
| | 64 (ops/second) | 0.00% | (R) -98.41% | (I) 4.91% |
| | 128 (ops/second) | 0.00% | (R) -98.38% | (I) 5.29% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| mmtests/stressng-wait | 1 (ops/second) | 0.00% | (R) -27.55% | 0.29% |
| | 2 (ops/second) | 0.00% | (R) -40.45% | 0.31% |
| | 4 (ops/second) | 0.00% | (R) -50.89% | 0.30% |
| | 8 (ops/second) | 0.00% | (R) -61.05% | 0.38% |
| | 16 (ops/second) | 0.00% | (R) -69.72% | -0.30% |
| | 32 (ops/second) | 0.00% | (R) -77.06% | 0.25% |
| | 64 (ops/second) | 0.00% | (R) -63.69% | (I) 7.23% |
| | 128 (ops/second) | 0.00% | (R) -84.87% | 1.74% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| mmtests/stressng-zombie | 1 (ops/second) | 0.00% | (R) -52.97% | (I) 4.73% |
| | 2 (ops/second) | 0.00% | (R) -75.01% | (I) 6.02% |
| | 4 (ops/second) | 0.00% | (R) -86.96% | (I) 5.61% |
| | 8 (ops/second) | 0.00% | (R) -92.74% | (I) 3.33% |
| | 16 (ops/second) | 0.00% | (R) -95.44% | (R) -2.01% |
| | 32 (ops/second) | 0.00% | (R) -95.90% | (R) -5.48% |
| | 64 (ops/second) | 0.00% | (R) -93.61% | -1.74% |
| | 128 (ops/second) | 0.00% | (R) -92.37% | -0.38% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| mmtests/sysbench-cpu | sysbenchcpu-1 (ops/second) | 0.00% | -0.04% | 0.07% |
| | sysbenchcpu-4 (ops/second) | 0.00% | (R) -75.01% | 0.04% |
| | sysbenchcpu-7 (ops/second) | 0.00% | (R) -85.72% | 0.03% |
| | sysbenchcpu-12 (ops/second) | 0.00% | (R) -91.67% | 0.04% |
| | sysbenchcpu-21 (ops/second) | 0.00% | (R) -95.24% | 0.04% |
| | sysbenchcpu-30 (ops/second) | 0.00% | (R) -96.67% | 0.04% |
| | sysbenchcpu-48 (ops/second) | 0.00% | (R) -97.92% | 0.04% |
| | sysbenchcpu-79 (ops/second) | 0.00% | (R) -98.44% | 0.06% |
| | sysbenchcpu-110 (ops/second) | 0.00% | (R) -98.44% | 0.06% |
| | sysbenchcpu-128 (ops/second) | 0.00% | (R) -98.44% | 0.06% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| mmtests/sysbench-mutex | sysbenchmutex-1 (usec) | 0.00% | 0.23% | -0.03% |
| | sysbenchmutex-4 (usec) | 0.00% | (R) 284.45% | -0.15% |
| | sysbenchmutex-7 (usec) | 0.00% | (R) 567.27% | -0.19% |
| | sysbenchmutex-12 (usec) | 0.00% | (R) 1039.06% | -0.18% |
| | sysbenchmutex-21 (usec) | 0.00% | (R) 1875.29% | -0.17% |
| | sysbenchmutex-30 (usec) | 0.00% | (R) 2688.51% | 0.03% |
| | sysbenchmutex-48 (usec) | 0.00% | (R) 3581.82% | -0.17% |
| | sysbenchmutex-79 (usec) | 0.00% | (R) 3955.59% | 2.50% |
| | sysbenchmutex-110 (usec) | 0.00% | (R) 3765.79% | -0.74% |
| | sysbenchmutex-128 (usec) | 0.00% | (R) 3795.09% | -1.24% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| mmtests/sysbench-thread | sysbenchthread-1 (usec) | 0.00% | 2.25% | 0.00% |
| | sysbenchthread-4 (usec) | 0.00% | (R) 366.16% | -2.60% |
| | sysbenchthread-7 (usec) | 0.00% | (R) 60.81% | 2.94% |
| | sysbenchthread-12 (usec) | 0.00% | (R) 650.47% | 8.35% |
| | sysbenchthread-21 (usec) | 0.00% | (R) 554.92% | -0.02% |
| | sysbenchthread-30 (usec) | 0.00% | (R) 578.98% | -7.29% |
| | sysbenchthread-48 (usec) | 0.00% | (R) 663.50% | -9.27% |
| | sysbenchthread-79 (usec) | 0.00% | (R) 418.80% | -10.92% |
| | sysbenchthread-110 (usec) | 0.00% | (R) 415.17% | -2.99% |
| | sysbenchthread-128 (usec) | 0.00% | (R) 384.96% | -0.34% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| pts/memtier-benchmark | Protocol: Redis Clients: 50 Ratio: 1:1 (Ops/sec) | 0.00% | (R) -98.14% | 0.69% |
| | Protocol: Redis Clients: 50 Ratio: 1:5 (Ops/sec) | 0.00% | (R) -98.20% | 0.87% |
| | Protocol: Redis Clients: 50 Ratio: 5:1 (Ops/sec) | 0.00% | (R) -98.20% | -0.48% |
| | Protocol: Redis Clients: 100 Ratio: 1:1 (Ops/sec) | 0.00% | (R) -98.38% | 0.52% |
| | Protocol: Redis Clients: 100 Ratio: 1:5 (Ops/sec) | 0.00% | (R) -98.04% | -1.36% |
| | Protocol: Redis Clients: 100 Ratio: 5:1 (Ops/sec) | 0.00% | (R) -97.87% | -0.92% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| pts/nginx | Connections: 200 (Requests Per Second) | 0.00% | (R) -98.12% | -0.46% |
| | Connections: 1000 (Requests Per Second) | 0.00% | (R) -98.21% | -1.01% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| pts/perl-benchmark | Test: Interpreter (Seconds) | 0.00% | -0.84% | -1.55% |
| | Test: Pod2html (Seconds) | 0.00% | 0.23% | -0.67% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| pts/pgbench | Scale: 1 Clients: 1 Read Only (TPS) | 0.00% | (R) -23.37% | -0.47% |
| | Scale: 1 Clients: 1 Read Only - Latency (ms) | 0.00% | (R) 32.35% | 0.98% |
| | Scale: 1 Clients: 1 Read Write (TPS) | 0.00% | (R) -6.06% | -0.67% |
| | Scale: 1 Clients: 1 Read Write - Latency (ms) | 0.00% | (R) 6.44% | 0.63% |
| | Scale: 1 Clients: 250 Read Only (TPS) | 0.00% | (R) -98.64% | -1.03% |
| | Scale: 1 Clients: 250 Read Only - Latency (ms) | 0.00% | (R) 7260.00% | 1.12% |
| | Scale: 1 Clients: 250 Read Write (TPS) | 0.00% | (R) -41.53% | -2.08% |
| | Scale: 1 Clients: 250 Read Write - Latency (ms) | 0.00% | (R) 70.84% | 2.04% |
| | Scale: 1 Clients: 1000 Read Only (TPS) | 0.00% | (R) -98.67% | -1.05% |
| | Scale: 1 Clients: 1000 Read Only - Latency (ms) | 0.00% | (R) 7430.55% | 1.08% |
| | Scale: 1 Clients: 1000 Read Write (TPS) | 0.00% | (R) -68.90% | -2.96% |
| | Scale: 1 Clients: 1000 Read Write - Latency (ms) | 0.00% | (R) 219.92% | 3.16% |
| | Scale: 100 Clients: 1 Read Only (TPS) | 0.00% | (R) -22.88% | -1.63% |
| | Scale: 100 Clients: 1 Read Only - Latency (ms) | 0.00% | (R) 28.07% | 0.00% |
| | Scale: 100 Clients: 1 Read Write (TPS) | 0.00% | (R) -9.13% | (R) -3.42% |
| | Scale: 100 Clients: 1 Read Write - Latency (ms) | 0.00% | (R) 10.10% | (R) 3.59% |
| | Scale: 100 Clients: 250 Read Only (TPS) | 0.00% | (R) -98.77% | -0.93% |
| | Scale: 100 Clients: 250 Read Only - Latency (ms) | 0.00% | (R) 8032.18% | 0.92% |
| | Scale: 100 Clients: 250 Read Write (TPS) | 0.00% | (R) -60.82% | -4.45% |
| | Scale: 100 Clients: 250 Read Write - Latency (ms) | 0.00% | (R) 155.11% | 5.44% |
| | Scale: 100 Clients: 1000 Read Only (TPS) | 0.00% | (R) -98.80% | -1.77% |
| | Scale: 100 Clients: 1000 Read Only - Latency (ms) | 0.00% | (R) 8223.51% | 1.85% |
| | Scale: 100 Clients: 1000 Read Write (TPS) | 0.00% | (R) -73.95% | -0.80% |
| | Scale: 100 Clients: 1000 Read Write - Latency (ms) | 0.00% | (R) 283.07% | 1.18% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| pts/pybench | Total For Average Test Times (Milliseconds) | 0.00% | -0.61% | -0.03% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| pts/redis | Test: GET Connections: 50 (Requests Per Second) | 0.00% | | -0.34% |
| | Test: GET Connections: 1000 (Requests Per Second) | 0.00% | | 0.69% |
| | Test: LPOP Connections: 50 (Requests Per Second) | 0.00% | | 0.07% |
| | Test: LPOP Connections: 1000 (Requests Per Second) | 0.00% | | 0.10% |
| | Test: LPUSH Connections: 50 (Requests Per Second) | 0.00% | | 0.09% |
| | Test: LPUSH Connections: 1000 (Requests Per Second) | 0.00% | | 0.03% |
| | Test: SADD Connections: 50 (Requests Per Second) | 0.00% | | -0.00% |
| | Test: SADD Connections: 1000 (Requests Per Second) | 0.00% | | -0.63% |
| | Test: SET Connections: 50 (Requests Per Second) | 0.00% | | 0.03% |
| | Test: SET Connections: 1000 (Requests Per Second) | 0.00% | | -1.39% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| pts/sqlite-speedtest | Timed Time - Size 1,000 (Seconds) | 0.00% | 1.69% | -0.62% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| speedometer/v2.0 | score (runs/min) | 0.00% | (R) -37.42% | 0.11% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
| speedometer/v2.1 | score (runs/min) | 0.00% | (R) -38.41% | 0.31% |
+------------------------------------+----------------------------------------------------------+-----------------+--------------+----------------------------+
Thanks,
Aishwarya
^ permalink raw reply [flat|nested] 6+ messages in thread