Patch "rtla/timerlat_aa: Fix previous IRQ delay for IRQs that happens after thread sample" has been added to the 6.5-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    rtla/timerlat_aa: Fix previous IRQ delay for IRQs that happens after thread sample

to the 6.5-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     rtla-timerlat_aa-fix-previous-irq-delay-for-irqs-tha.patch
and it can be found in the queue-6.5 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 32d1d6c52b443906f6261c8a6b262b32ed82201d
Author: Daniel Bristot de Oliveira <bristot@xxxxxxxxxx>
Date:   Fri Aug 4 17:52:13 2023 +0200

    rtla/timerlat_aa: Fix previous IRQ delay for IRQs that happens after thread sample
    
    [ Upstream commit 301deca09b254965661d3e971f1a60ac2ce41f5f ]
    
    timerlat auto-analysis takes note of all IRQs, before or after the
    execution of the timerlat thread.
    
    Because we cannot go backward in the trace (we will fix it when
    moving to trace-cmd lib?), timerlat aa take note of the last IRQ
    execution in the waiting for the IRQ state, and then print it
    if it is executed after the expected timer IRQ starting time.
    
    After the thread sample, the timerlat starts recording the next IRQs as
    "previous" irq for the next occurrence.
    
    However, if an IRQ happens after the thread measurement but before the
    tracing stops, it is classified as a previous IRQ. That is not
    wrong, as it can be "previous" for the subsequent activation. What is
    wrong is considering it as a potential source for the last activation.
    
    Ignore the IRQ interference that happens after the IRQ starting time for
    now. A future improvement for timerlat can be either keeping a list of
    previous IRQ execution or using the trace-cmd library. Still, it requires
    further investigation - it is a new feature.
    
    Link: https://lore.kernel.org/lkml/a44a3f5c801dcc697bacf7325b65d4a5b0460537.1691162043.git.bristot@xxxxxxxxxx
    
    Fixes: 27e348b221f6 ("rtla/timerlat: Add auto-analysis core")
    Signed-off-by: Daniel Bristot de Oliveira <bristot@xxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/tools/tracing/rtla/src/timerlat_aa.c b/tools/tracing/rtla/src/timerlat_aa.c
index baf1efda0581d..7093fd5333beb 100644
--- a/tools/tracing/rtla/src/timerlat_aa.c
+++ b/tools/tracing/rtla/src/timerlat_aa.c
@@ -545,7 +545,7 @@ static int timerlat_aa_kworker_start_handler(struct trace_seq *s, struct tep_rec
 static void timerlat_thread_analysis(struct timerlat_aa_data *taa_data, int cpu,
 				     int irq_thresh, int thread_thresh)
 {
-	unsigned long long exp_irq_ts;
+	long long exp_irq_ts;
 	int total;
 	int irq;
 
@@ -562,12 +562,15 @@ static void timerlat_thread_analysis(struct timerlat_aa_data *taa_data, int cpu,
 
 	/*
 	 * Expected IRQ arrival time using the trace clock as the base.
+	 *
+	 * TODO: Add a list of previous IRQ, and then run the list backwards.
 	 */
 	exp_irq_ts = taa_data->timer_irq_start_time - taa_data->timer_irq_start_delay;
-
-	if (exp_irq_ts < taa_data->prev_irq_timstamp + taa_data->prev_irq_duration)
-		printf("  Previous IRQ interference:	\t\t up to  %9.2f us\n",
-			ns_to_usf(taa_data->prev_irq_duration));
+	if (exp_irq_ts < taa_data->prev_irq_timstamp + taa_data->prev_irq_duration) {
+		if (taa_data->prev_irq_timstamp < taa_data->timer_irq_start_time)
+			printf("  Previous IRQ interference:	\t\t up to  %9.2f us\n",
+				ns_to_usf(taa_data->prev_irq_duration));
+	}
 
 	/*
 	 * The delay that the IRQ suffered before starting.



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux