From patchwork Thu May 11 16:32:01 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Bristot de Oliveira X-Patchwork-Id: 92733 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp4515799vqo; Thu, 11 May 2023 09:39:54 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7T7I2peqkiVolxKJleB4BX7HLqNARVn3RVqlw/Zlc8S75Xsl7BbKeYvLUufONW7yLv6Npi X-Received: by 2002:a17:903:1249:b0:1a9:5aef:1aea with SMTP id u9-20020a170903124900b001a95aef1aeamr26361864plh.66.1683823194105; Thu, 11 May 2023 09:39:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683823194; cv=none; d=google.com; s=arc-20160816; b=BRZ6LbIeGD283UDYTjY44qEI4bBdvhdRhqudP4ccv9kaGUKVAPnIfuQ+UNczY9R1yv aai9b24k4a30QR+E4BJB84N3IeylSZoVTpd9rmqYf+UM35O3taZr4tZe+XCElatUDif5 wnSkpcYL/m9Rrg5Fc3Kzk96BbRJAjdw9/3N5lt5LS+Y2ZGlX0vTlw2fipB2QL599a5bN 9ekrTPR8UmXJJ4GFtiPdENs1eCAZpCy8uIWm4yDKSfXtVDuofp1or3Qe4lyZZdg+BgsA mcseG0BnLOX53IHEcZt0Zd2SnJbTNug8I0fbA0K4QaczYQTUw/x2yd8QxY7Hgo9o8uKc rNSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=ahTPF+YBNfFtmzNfn3gXquSLrLdYzEJuctX5rQb0eok=; b=gHlkKJTBAvB0qp5/yNLrpBriAZnzzm339oPMqAAoXsptBEwYncTIWC4XfZry9CdMte jDZuVSCKp8GNFEpz7npTCifs4uYm3w6O1A8DRvTHiKmGikpI+lNM9FY2Ex5o0izphGV+ E/9X9hwqNeR1SMf4RloEbWwXpn4IdDRp0YdiP4F7qhnKRERox07x1/mW9MWAlhTFxLVy tC9PTWZ5C1z+nZmnOAo8WF49ghAVDQOEJ6boL131fRsETrZix1p7U+S6JKx/Y7A0N0eT UA3W2fz7r7CNsXPeGN+I4ijAp95Tr2ax1Tg6OnUDI7ayKml6SLgmUrdiZqcL6ShN8MLE WwAg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=tpvaftI0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j12-20020a170902690c00b001aaee4e18dbsi6873835plk.379.2023.05.11.09.39.41; Thu, 11 May 2023 09:39:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=tpvaftI0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238461AbjEKQc6 (ORCPT + 99 others); Thu, 11 May 2023 12:32:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47834 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232501AbjEKQc5 (ORCPT ); Thu, 11 May 2023 12:32:57 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B68F386A9; Thu, 11 May 2023 09:32:20 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3291A64F9A; Thu, 11 May 2023 16:32:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 190FEC433EF; Thu, 11 May 2023 16:32:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1683822731; bh=gW/QVNiiP32Xg88rYdghCZ+KlKF0J2C2taBsF0+taHY=; h=From:To:Cc:Subject:Date:From; b=tpvaftI0Sc3sYeCtaAg/M0g/a11Fjw5Ofo/Yfwc7yuvArvH/1gdurhWGWRXg4nTOj Zi0x4Nkwg7TqsEJlfRHWUJqY6IcKjKIZsQKX5O0qUNZo7A2M7zCWktVQEHeJ33d3K/ d0yHpYRhk3c683Tn/tDKr84n2L3a2p3U7Ziaoj+uc2Sk7K1DTVNdrZRy1TeTILjXxm qMljSKfau5dVdwjha4u5/fq82vfL3fvUr57l1tsTGYdFEsN9UMi/VROQA2aGIJG3up wsj7Ibt2ocFLOqk5HXDWLFs9pHrsjzbxwFm9edGrjS/FpggdX4u/QttQULgqZH6Aho 6YTeQ03H1U6gQ== From: Daniel Bristot de Oliveira To: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, Steven Rostedt Cc: Daniel Bristot de Oliveira , Juri Lelli , Masami Hiramatsu Subject: [PATCH] tracing/timerlat: Always wakeup the timerlat thread Date: Thu, 11 May 2023 18:32:01 +0200 Message-Id: <1ed8f830638b20a39d535d27d908e319a9a3c4e2.1683822622.git.bristot@kernel.org> X-Mailer: git-send-email 2.38.1 MIME-Version: 1.0 X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1765616589505867052?= X-GMAIL-MSGID: =?utf-8?q?1765616589505867052?= While testing rtla timerlat auto analysis, I reach a condition where the interface was not receiving tracing data. I was able to manually reproduce the problem with these steps: # echo 0 > tracing_on # disable trace # echo 1 > osnoise/stop_tracing_us # stop trace if timerlat irq > 1 us # echo timerlat > current_tracer # enable timerlat tracer # sleep 1 # wait... that is the time when rtla # apply configs like prio or cgroup # echo 1 > tracing_on # start tracing # cat trace # tracer: timerlat # # _-----=> irqs-off # / _----=> need-resched # | / _---=> hardirq/softirq # || / _--=> preempt-depth # ||| / _-=> migrate-disable # |||| / delay # ||||| ACTIVATION # TASK-PID CPU# ||||| TIMESTAMP ID CONTEXT LATENCY # | | | ||||| | | | | NOTHING! Then, trying to enable tracing again with echo 1 > tracing_on resulted in no change: the trace was still not tracing. This problem happens because the timerlat IRQ hits the stop tracing condition while tracing is off, and do not wake up the timerlat thread, so the timerlat threads are kept sleeping forever, resulting in no trace, even after re-enabling the tracer. Avoid this condition by always waking up the threads, even after stopping tracing, allowing the tracer to return to its normal operating after a new tracing on. Cc: Steven Rostedt Cc: Daniel Bristot de Oliveira Cc: Masami Hiramatsu Fixes: a955d7eac177 ("trace: Add timerlat tracer") Signed-off-by: Daniel Bristot de Oliveira --- kernel/trace/trace_osnoise.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/trace/trace_osnoise.c b/kernel/trace/trace_osnoise.c index efbbec2caff8..e97e3fa5cbed 100644 --- a/kernel/trace/trace_osnoise.c +++ b/kernel/trace/trace_osnoise.c @@ -1652,6 +1652,8 @@ static enum hrtimer_restart timerlat_irq(struct hrtimer *timer) osnoise_stop_tracing(); notify_new_max_latency(diff); + wake_up_process(tlat->kthread); + return HRTIMER_NORESTART; } }