All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julian Sikorski <belegdol@gmail.com>
To: Kuan-Wei Chiu <visitorckw@gmail.com>, rafael@kernel.org
Cc: lenb@kernel.org, mario.limonciello@amd.com,
	akpm@linux-foundation.org, jserv@ccns.ncku.edu.tw,
	alexdeucher@gmail.com, regressions@leemhuis.info,
	linux-acpi@vger.kernel.org, regressions@lists.linux.dev,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v4] ACPI: processor_idle: Fix invalid comparison with insertion sort for latency
Date: Tue, 2 Jul 2024 09:28:39 +0200	[thread overview]
Message-ID: <81aa100e-044c-4ea8-a2ff-cd34711e137e@gmail.com> (raw)
In-Reply-To: <20240701205639.117194-1-visitorckw@gmail.com>

Am 01.07.24 um 22:56 schrieb Kuan-Wei Chiu:
> The acpi_cst_latency_cmp comparison function currently used for sorting
> C-state latencies does not satisfy transitivity, causing incorrect
> sorting results. Specifically, if there are two valid acpi_processor_cx
> elements A and B and one invalid element C, it may occur that A < B,
> A = C, and B = C. Sorting algorithms assume that if A < B and A = C,
> then C < B, leading to incorrect ordering.
> 
> Given the small size of the array (<=8), we replace the library sort
> function with a simple insertion sort that properly ignores invalid
> elements and sorts valid ones based on latency. This change ensures
> correct ordering of the C-state latencies.
> 
> Fixes: 65ea8f2c6e23 ("ACPI: processor idle: Fix up C-state latency if not ordered")
> Cc: stable@vger.kernel.org
> Reported-by: Julian Sikorski <belegdol@gmail.com>
> Closes: https://lore.kernel.org/lkml/70674dc7-5586-4183-8953-8095567e73df@gmail.com/
> Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
> ---
> v3 -> v4:
> - Rename the parameter 'arr' to 'states'.
> - Add empty lines to enhance readability.
> 
> Note: I only performed a build test and a simple unit test to ensure
>        the latency of valid elements is correctly sorted in the randomly
>        generated data.
> 

Hello,

thanks for the patch. I have tested this applied on top of Fedora 6.9.7 
kernel on my Asus laptop and the message about suspend not reaching the 
deepest state is gone. Thank you.
I wonder whether this will also fix random S3 suspend issues I have been 
seeing on my 5600x since 6.9 kernel too. I will definitely try.

Best regards,
Julian

Tested-by: Julian Sikorski <belegdol@gmail.com>

>   drivers/acpi/processor_idle.c | 37 +++++++++++++++--------------------
>   1 file changed, 16 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
> index bd6a7857ce05..831fa4a12159 100644
> --- a/drivers/acpi/processor_idle.c
> +++ b/drivers/acpi/processor_idle.c
> @@ -16,7 +16,6 @@
>   #include <linux/acpi.h>
>   #include <linux/dmi.h>
>   #include <linux/sched.h>       /* need_resched() */
> -#include <linux/sort.h>
>   #include <linux/tick.h>
>   #include <linux/cpuidle.h>
>   #include <linux/cpu.h>
> @@ -386,25 +385,24 @@ static void acpi_processor_power_verify_c3(struct acpi_processor *pr,
>   	acpi_write_bit_register(ACPI_BITREG_BUS_MASTER_RLD, 1);
>   }
>   
> -static int acpi_cst_latency_cmp(const void *a, const void *b)
> +static void acpi_cst_latency_sort(struct acpi_processor_cx *states, size_t length)
>   {
> -	const struct acpi_processor_cx *x = a, *y = b;
> +	int i, j, k;
>   
> -	if (!(x->valid && y->valid))
> -		return 0;
> -	if (x->latency > y->latency)
> -		return 1;
> -	if (x->latency < y->latency)
> -		return -1;
> -	return 0;
> -}
> -static void acpi_cst_latency_swap(void *a, void *b, int n)
> -{
> -	struct acpi_processor_cx *x = a, *y = b;
> +	for (i = 1; i < length; i++) {
> +		if (!states[i].valid)
> +			continue;
>   
> -	if (!(x->valid && y->valid))
> -		return;
> -	swap(x->latency, y->latency);
> +		for (j = i - 1, k = i; j >= 0; j--) {
> +			if (!states[j].valid)
> +				continue;
> +
> +			if (states[j].latency > states[k].latency)
> +				swap(states[j].latency, states[k].latency);
> +
> +			k = j;
> +		}
> +	}
>   }
>   
>   static int acpi_processor_power_verify(struct acpi_processor *pr)
> @@ -449,10 +447,7 @@ static int acpi_processor_power_verify(struct acpi_processor *pr)
>   
>   	if (buggy_latency) {
>   		pr_notice("FW issue: working around C-state latencies out of order\n");
> -		sort(&pr->power.states[1], max_cstate,
> -		     sizeof(struct acpi_processor_cx),
> -		     acpi_cst_latency_cmp,
> -		     acpi_cst_latency_swap);
> +		acpi_cst_latency_sort(&pr->power.states[1], max_cstate);
>   	}
>   
>   	lapic_timer_propagate_broadcast(pr);


  reply	other threads:[~2024-07-02  7:28 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-13  3:13 [PATCH 0/2] lib/sort: Optimize the number of swaps and comparisons Kuan-Wei Chiu
2024-01-13  3:13 ` [PATCH 1/2] lib/sort: Optimize heapsort for equal elements in sift-down path Kuan-Wei Chiu
2024-01-13  3:13 ` [PATCH 2/2] lib/sort: Optimize heapsort with double-pop variation Kuan-Wei Chiu
2024-06-20 15:36   ` Julian Sikorski
2024-06-20 20:17     ` Mario Limonciello
2024-06-28 15:15     ` Linux regression tracking (Thorsten Leemhuis)
2024-06-28 17:10       ` Kuan-Wei Chiu
2024-06-29  5:03         ` Linux regression tracking (Thorsten Leemhuis)
2024-06-30 21:08           ` [PATCH] ACPI: processor_idle: Fix invalid comparison with insertion sort for latency Kuan-Wei Chiu
2024-06-30 21:13             ` Kuan-Wei Chiu
2024-07-01  4:42               ` [PATCH v2] " Kuan-Wei Chiu
2024-07-01  5:06                 ` Greg KH
2024-07-01 15:17                 ` Mario Limonciello
2024-07-01 16:10                   ` [PATCH v3] " Kuan-Wei Chiu
2024-07-01 17:36                     ` Rafael J. Wysocki
2024-07-01 20:56                       ` [PATCH v4] " Kuan-Wei Chiu
2024-07-02  7:28                         ` Julian Sikorski [this message]
2024-07-02 12:59                           ` Mario Limonciello
2024-07-02 18:38                         ` Rafael J. Wysocki
2025-01-15  3:27     ` [PATCH 2/2] lib/sort: Optimize heapsort with double-pop variation Luke Jones
2025-01-15 12:49       ` Kuan-Wei Chiu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=81aa100e-044c-4ea8-a2ff-cd34711e137e@gmail.com \
    --to=belegdol@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexdeucher@gmail.com \
    --cc=jserv@ccns.ncku.edu.tw \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --cc=rafael@kernel.org \
    --cc=regressions@leemhuis.info \
    --cc=regressions@lists.linux.dev \
    --cc=stable@vger.kernel.org \
    --cc=visitorckw@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.