Received: by 2002:a05:6a10:8395:0:0:0:0 with SMTP id n21csp609353pxh; Tue, 9 Nov 2021 16:07:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJxiGmVLe88hGDBY2WuiQ1H1FME4DFAotE4mxEnrHz3jLHD+J2KuQ7rL4dBo0vz2JLcPlJ93 X-Received: by 2002:a50:cc07:: with SMTP id m7mr15662385edi.356.1636502869176; Tue, 09 Nov 2021 16:07:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1636502869; cv=none; d=google.com; s=arc-20160816; b=WS6I1Jck087Zusl/1NWSgUOFSLpO3MBJK8r31QCRwNysvXJIYZPuh3vH5eca1249wf s7EZPfO4/BYjAUEeAeTURHP9zmZbJaltkfLD7pmBJHqpswLXGedsm0VQ5zgdHIN76OFN bVxgug9zz6zhL7Hz0AiEqNZn8RRiW8C8BVXWfJmc6FCLqG53iSVzBPlECZAfEa6yLCAB eFr2wxu3hk0Wyj7zLi0TSui6+wc62nbXk8Qun1gMbqClDLvF+tMmCIIJJTcTyCr7tEjA zDpfT3ceUE5Jf05U1/HSovL529nw32fpCO07A1ouOQssVX+w1CFZHmWhzTJzrpReIyvw yVEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=arA5NuLJ5w1GwDIRETabm4JkNQQtn8VKJ8rknKRj7tQ=; b=XknV0qi2tozju7c9Gpt5jaNb4CsOccck3HgmQbK0/APHOKqrFzAnsRypfhKZp9jBfV dTrbXxoYlk0MtzuInvOJBhey1RLQaJWhIwQESW8NOdw0r5df3LYw+J6cFexwRNdumBhz PN7q6FSLiRVMDgsF/HqbssUu8/5lZZe7LEzVNhiIM6Iri4pIRRS33hSFhX8OpmBHO42c 01Fl0ZegE7C09c+K6uzbVsbrToj28L50lGAiFkWwbGEp7b/4yFByLTJyR/cHJcCBsEUr nn9cb8VdNoHM0y0Q1jzArfvaH4Xe+vVaBOxMxzdM+eEyJtaPzLvfOvUXxyF5RKDWylxg P1NA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcdkim header.b=tUEz+xgg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id sa10si25450252ejc.458.2021.11.09.16.07.26; Tue, 09 Nov 2021 16:07:49 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcdkim header.b=tUEz+xgg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238808AbhKIQZY (ORCPT + 97 others); Tue, 9 Nov 2021 11:25:24 -0500 Received: from alexa-out-sd-01.qualcomm.com ([199.106.114.38]:17281 "EHLO alexa-out-sd-01.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238397AbhKIQZX (ORCPT ); Tue, 9 Nov 2021 11:25:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim; t=1636474957; x=1668010957; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=arA5NuLJ5w1GwDIRETabm4JkNQQtn8VKJ8rknKRj7tQ=; b=tUEz+xggtXFmVp97lOJAA+hJaiSjYaIuP7SQD1+cS8qxLDKtvHapuLnP BwJsAXq1Ly1tM4e456tpxCu70oxO5WPAIXDia972njxkTurWkU9YuFTPR YbgtQ8Qawg9JOqsNAJo2sUbbUC3V9SSZ5EQy6w+FIXlFgCO7DYff38HK2 s=; Received: from unknown (HELO ironmsg03-sd.qualcomm.com) ([10.53.140.143]) by alexa-out-sd-01.qualcomm.com with ESMTP; 09 Nov 2021 08:22:36 -0800 X-QCInternal: smtphost Received: from nasanex01c.na.qualcomm.com ([10.47.97.222]) by ironmsg03-sd.qualcomm.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Nov 2021 08:22:36 -0800 Received: from nalasex01a.na.qualcomm.com (10.47.209.196) by nasanex01c.na.qualcomm.com (10.47.97.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.7; Tue, 9 Nov 2021 08:22:36 -0800 Received: from [10.50.19.148] (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.7; Tue, 9 Nov 2021 08:22:30 -0800 Message-ID: Date: Tue, 9 Nov 2021 21:52:26 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.1.2 Subject: Re: [PATCHv3 3/3] dynamic_debug: Add a flag for dynamic event tracing Content-Language: en-US To: Steven Rostedt CC: Will Deacon , Catalin Marinas , , Marc Zyngier , , , , , , , , References: <3706af20bc64a320ff8f3ff8950738b988f4bdf5.1636452784.git.quic_saipraka@quicinc.com> <20211109104941.2d50eafc@gandalf.local.home> From: Sai Prakash Ranjan In-Reply-To: <20211109104941.2d50eafc@gandalf.local.home> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To nalasex01a.na.qualcomm.com (10.47.209.196) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Steve, On 11/9/2021 9:19 PM, Steven Rostedt wrote: > On Tue, 9 Nov 2021 17:38:21 +0530 > Sai Prakash Ranjan wrote: > >> Debugging a specific driver or subsystem can be a lot easier if we can >> trace events specific to that driver or subsystem. This type of >> filtering can be achieved using existing dynamic debug library which >> provides a way to filter based on files, functions and modules. >> >> Using this, provide an additional flag 'e' to filter event tracing to >> specified input. >> >> For example, tracing all MMIO read/write can be overwhelming and of no >> use when debugging a specific driver or a subsystem. So switch to >> dynamic event tracing for register accesses. >> >> Example: Tracing register accesses for all drivers in drivers/soc/qcom/* >> and the trace output is given below: >> >> # dyndbg="file drivers/soc/qcom/* +e" trace_event=rwmmio >> or >> # echo "file drivers/soc/qcom/* +e" > /sys/kernel/debug/dynamic_debug/control >> # cat /sys/kernel/debug/tracing/trace > FYI, it's best to use /sys/kernel/tracing, as the debug/tracing is only > there for backward compatibility. Ah I see, will correct it. >> rwmmio_read: rpmh_rsc_probe+0x35c/0x410 readl addr=0xffff80001071000c >> rwmmio_read: rpmh_rsc_probe+0x3d0/0x410 readl addr=0xffff800010710004 >> rwmmio_write: rpmh_rsc_probe+0x3b0/0x410 writel addr=0xffff800010710d00 val=0x3 >> rwmmio_write: write_tcs_cmd+0x6c/0x78 writel addr=0xffff800010710d30 val=0x10108 > I'd much rather have a module name or something attached to the event that > ca be filtered on via the trace event filters, than having it determined by > some side effect done in another directory. I presume we don't have CALLER_MODULENAME0,1,2.. like CALLER_ADDR0,1,2 without which we cannot insert the module name to this trace event since MMIO accessors are defined in low level arch headers and we won't get any useful module information from where these accessors are called. The function name and the offset is good enough to identify the exact line and module after post-processing with tools like GDB, objdump, so I feel we can keep the trace event fields limited? Thanks, Sai > > -- Steve