From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B287FC433FE for ; Thu, 17 Feb 2022 23:55:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2177A6B007D; Thu, 17 Feb 2022 18:55:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1C7616B007E; Thu, 17 Feb 2022 18:55:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 069756B0080; Thu, 17 Feb 2022 18:55:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0159.hostedemail.com [216.40.44.159]) by kanga.kvack.org (Postfix) with ESMTP id EB9D36B007D for ; Thu, 17 Feb 2022 18:55:16 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id A85E58F840 for ; Thu, 17 Feb 2022 23:55:16 +0000 (UTC) X-FDA: 79153930632.16.FF2F8E8 Received: from lgeamrelo11.lge.com (lgeamrelo12.lge.com [156.147.23.52]) by imf06.hostedemail.com (Postfix) with ESMTP id 50412180002 for ; Thu, 17 Feb 2022 23:55:13 +0000 (UTC) Received: from unknown (HELO lgemrelse7q.lge.com) (156.147.1.151) by 156.147.23.52 with ESMTP; 18 Feb 2022 08:55:11 +0900 X-Original-SENDERIP: 156.147.1.151 X-Original-MAILFROM: byungchul.park@lge.com Received: from unknown (HELO X58A-UD3R) (10.177.244.38) by 156.147.1.151 with ESMTP; 18 Feb 2022 08:55:11 +0900 X-Original-SENDERIP: 10.177.244.38 X-Original-MAILFROM: byungchul.park@lge.com Date: Fri, 18 Feb 2022 08:55:04 +0900 From: Byungchul Park To: Steven Rostedt Cc: Linus Torvalds , Damien Le Moal , linux-ide@vger.kernel.org, Ingo Molnar , Linux Kernel Mailing List , Peter Zijlstra , Will Deacon , Thomas Gleixner , Joel Fernandes , Sasha Levin , Daniel Vetter , Chris Wilson , duyuyang@gmail.com, johannes.berg@intel.com, Tejun Heo , Theodore Ts'o , Matthew Wilcox , Dave Chinner , Amir Goldstein , "J. Bruce Fields" , Greg Kroah-Hartman , kernel-team@lge.com, Linux-MM , Andrew Morton , Michal Hocko , Minchan Kim , Johannes Weiner , Vladimir Davydov , sj@kernel.org, Jerome Glisse , Dennis Zhou , Christoph Lameter , Pekka Enberg , David Rientjes , Vlastimil Babka , ngupta@vflare.org, linux-block , Jens Axboe , paolo.valente@linaro.org, Josef Bacik , linux-fsdevel , Al Viro , Jan Kara , Jeff Layton , Dan Williams , Christoph Hellwig , "Darrick J. Wong" , dri-devel , Dave Airlie , rodrigosiqueiramelo@gmail.com, melissa.srw@gmail.com, hamohammed.sa@gmail.com Subject: Re: Report in ata_scsi_port_error_handler() Message-ID: <20220217235504.GB20620@X58A-UD3R> References: <1644984747-26706-1-git-send-email-byungchul.park@lge.com> <1644984964-28300-1-git-send-email-byungchul.park@lge.com> <1644984964-28300-3-git-send-email-byungchul.park@lge.com> <94b1cba2-0e78-bbc0-0321-8be70b2b3be2@opensource.wdc.com> <20220216133318.204f36ac@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220216133318.204f36ac@gandalf.local.home> User-Agent: Mutt/1.5.21 (2010-09-15) Authentication-Results: imf06.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf06.hostedemail.com: domain of byungchul.park@lge.com designates 156.147.23.52 as permitted sender) smtp.mailfrom=byungchul.park@lge.com X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 50412180002 X-Stat-Signature: rgdh9ti59yqz5ntuw8w6pjdf43t3qjnd X-HE-Tag: 1645142113-587080 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Feb 16, 2022 at 01:33:18PM -0500, Steven Rostedt wrote: > On Wed, 16 Feb 2022 10:09:14 -0800 > Linus Torvalds wrote: > > > Byungchul, could you fix those two issues? Some of your reports may > > well be entirely valid, but the hard-to-read hex offsets and the > > knowledge that at least some of them are confused about how > > prepare_to_wait -> wait actually works makes the motivation to look at > > the details much less.. > > Hi Byungchul, > > I'm not sure what your tool is using to attach to the kernel to analyze the > events (perhaps tracepoints?). But you can have the prepare_to_wait event > just flag the task is about to wait, and then attach to the schedule > (sched_switch) event to denote that it actually waited. > > Of course have the finish_wait() clear the flag. (Sorry for late reply, which was because of my email client issue.) Thank you for the hint. However, unfortunately, I didn't use tracepoint for that. However, the key idea is the thing that I should take! Thanks a lot! Thanks, Byungchul > > -- Steve