From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752475AbdJ3KHG (ORCPT ); Mon, 30 Oct 2017 06:07:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47954 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751702AbdJ3KHF (ORCPT ); Mon, 30 Oct 2017 06:07:05 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 311DDC056861 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=vkuznets@redhat.com From: Vitaly Kuznetsov To: Greg KH Cc: kys@microsoft.com, linux-kernel@vger.kernel.org, devel@linuxdriverproject.org, olaf@aepfle.de, apw@canonical.com, jasowang@redhat.com, leann.ogasawara@canonical.com, marcelo.cerri@canonical.com, sthemmin@microsoft.com, Steven Rostedt Subject: Re: [PATCH 10/17] hyper-v: trace vmbus_open() References: <20171029192030.12356-1-kys@exchange.microsoft.com> <20171029192116.12466-1-kys@exchange.microsoft.com> <20171029192116.12466-10-kys@exchange.microsoft.com> <20171029205958.GA30187@kroah.com> <877evdyrsc.fsf@vitty.brq.redhat.com> <20171030084537.GA14865@kroah.com> Date: Mon, 30 Oct 2017 11:07:01 +0100 In-Reply-To: <20171030084537.GA14865@kroah.com> (Greg KH's message of "Mon, 30 Oct 2017 09:45:37 +0100") Message-ID: <873761ymnu.fsf@vitty.brq.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Mon, 30 Oct 2017 10:07:05 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Greg KH writes: > On Mon, Oct 30, 2017 at 09:16:19AM +0100, Vitaly Kuznetsov wrote: >> Greg KH writes: >> >> > On Sun, Oct 29, 2017 at 12:21:09PM -0700, kys@exchange.microsoft.com wrote: >> >> From: Vitaly Kuznetsov >> >> >> >> Add tracepoint to CHANNELMSG_OPENCHANNEL sender. >> >> >> >> Signed-off-by: Vitaly Kuznetsov >> >> Signed-off-by: K. Y. Srinivasan >> >> --- >> >> drivers/hv/channel.c | 2 ++ >> >> drivers/hv/hv_trace.h | 27 +++++++++++++++++++++++++++ >> >> 2 files changed, 29 insertions(+) >> >> >> >> diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c >> >> index a406beb10dd0..739b3fe1e0fb 100644 >> >> --- a/drivers/hv/channel.c >> >> +++ b/drivers/hv/channel.c >> >> @@ -185,6 +185,8 @@ int vmbus_open(struct vmbus_channel *newchannel, u32 send_ringbuffer_size, >> >> ret = vmbus_post_msg(open_msg, >> >> sizeof(struct vmbus_channel_open_channel), true); >> >> >> >> + trace_vmbus_open(open_msg, ret); >> > >> > Why add tracepoints for things that ftrace can handle automatically? >> >> This series adds pretty prints for structures printing what is needed >> and in the right format significantly simplifying debugging. And it >> wouldn't make sense to add tracepoints to *some* messages-related >> functions and skip others where parsing is more trivial. > > Tracepoints add memory usage and take up real space. If you don't need > them for something, as there are other ways to already get the > information needed, why add new ones that you now need to drag around > for all time? > Are you opposed to the series as a whole (AKA 'no tracepoints in drivers') or only to some tracepoints we add here? Debugging stuff is always a tradeof between some memory overhead and convenience (and CONFIG_TRACEPOINTS is the knob). Here I'd like to see vmbus_* structures parsed in output. When things go wrong I can tell someone "do echo 1 > /sys/kernel/debug/tracing/events/hyperv/enable and show me the output" and I will have enough information to figure out what's going on. I'm probably missing something about easy 'alternative' ways to get what I need and why people add tracepoints to drivers in general. -- Vitaly