Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751182AbdFBKYs (ORCPT ); Fri, 2 Jun 2017 06:24:48 -0400 Received: from mga09.intel.com ([134.134.136.24]:2598 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751124AbdFBKYr (ORCPT ); Fri, 2 Jun 2017 06:24:47 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,284,1493708400"; d="asc'?scan'208";a="93955573" From: Felipe Balbi To: Chunyan Zhang Cc: Alexander Shishkin , Steven Rostedt , Ingo Molnar , "linux-kernel\@vger.kernel.org" , Mathieu Poirier Subject: Re: Ftrace Data Export In-Reply-To: References: <87a86bx5vx.fsf@linux.intel.com> Date: Fri, 02 Jun 2017 13:24:07 +0300 Message-ID: <874lvyvgag.fsf@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2423 Lines: 70 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, (sorry for the long delay, just back from vacations) Chunyan Zhang writes: > Hi Felipe, > > On 17 May 2017 at 16:08, Felipe Balbi wrot= e: >> >> Hi Chunyan, >> >> When you wrote your patchset to provide ftrace exports, why did you >> choose to export only function trace? Why not tracepoints, > > In fact, I tried submitting patches[1] to do exporting tracepoint to > STM, but Ingo and Steven commented that would introduce certain amount > of overhead, and that was not acceptable. I also used > 'benchmark_event' to see the additional overhead caused by printing > tracepoint message to STM. I cannot remember the exact data though, > the increased time consuming indeed was non-ignorable. > > So at the end I gave up that idea, and later on switched to the way of > implementation you see in the kernel now. Were you decoding the data before off-loading it to the trace export? Maybe that's why they consider it an extra overhead? Have you considered off-loading raw data for further post processing? >> function_graph, hwlat, irqsoff and all the other possibilities? > > I haven't thought about these clear enough :) > Any suggestion? I think we should be able to export everything and anything :-p But, of course, we would need tooling to decode it after the fact. > [1] https://lkml.org/lkml/2015/7/7/230 hmm, lkml.org seems to be down. =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEElLzh7wn96CXwjh2IzL64meEamQYFAlkxPMcACgkQzL64meEa mQZ8vQ//Q9SRpoqTCAUAFzz5J/L2GOZTqClr8G9bBYAoeJ0KuL3z83OuO6iY94MJ Qp6pCqdBjsnKOINiLaRC1T8heVSpCWkSLlgHowC+7NrzGhT86MMADWkzRuXfmim8 JNM27bgOfYlnaMUkJ1ew6xq61jFZG7LPv+ySQxIy3971yoBYSGC8B4eMm+4Db4Vv 4DgVFF5ZJRNFg/sLIjaysLBMJ+87s0UuwHnuBdZsRWOa4nqBiHPGTEb3GkznPDli zH8eUafCVm0Li6fzzcAYCBfgDyBFQb18z+plpd0z0rxCfS8YfvoVYkkz7Q8Io6Rg cJIGpdHZPU+lpogxNUvI1RmVk4Dt7WWZB7PHft+qw7I7abzmd6rElIf0OlQHAaJ5 h8v0vC/QqWW5E2VzE5LFX2HPC/VwMThpCyIcRLP6j22OqttwyFL2Xc0F+ZQzGkp4 ZKva6qq8+fFDMKFJ8sW6vpCJvOkKEs+zYrv+hM/FrWeJj7qkkb6YmvqudD8yz8NG 9Ih1N8jdSYmroHxV4jbn1JRqemuQoH2ef/l6ay+8ZKhN/V5ySfAHwZSRW3qgnVMf GdMZsMoZldshv5SEYjMhCPpPaWAHI7q9kSNpw/S9s6dw/Vx61QpPzBeEao7pCzLN JYtQ/cq/gBiPd2PzcWm3KPmpJdh3PjO9PRyom+RMw5XHemE2km0= =gbLg -----END PGP SIGNATURE----- --=-=-=--