Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932873AbbFVHem (ORCPT ); Mon, 22 Jun 2015 03:34:42 -0400 Received: from mail.bmw-carit.de ([62.245.222.98]:56847 "EHLO mail.bmw-carit.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756034AbbFVHec (ORCPT ); Mon, 22 Jun 2015 03:34:32 -0400 X-CTCH-RefID: str=0001.0A0C0201.5587BA81.0287,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0 Message-ID: <5587BA7A.6050208@bmw-carit.de> Date: Mon, 22 Jun 2015 09:34:18 +0200 From: Daniel Wagner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Daniel Borkmann , Alexei Starovoitov CC: "David S. Miller" , Ingo Molnar , , Subject: Re: [PATCH v2] bpf: BPF based latency tracing References: <1434722444-10200-1-git-send-email-daniel.wagner@bmw-carit.de> <558520DB.6000904@iogearbox.net> In-Reply-To: <558520DB.6000904@iogearbox.net> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1314 Lines: 34 On 06/20/2015 10:14 AM, Daniel Borkmann wrote: > I think it would be useful to perhaps have two options: > > 1) User specifies a specific CPU and gets one such an output above. Good point. Will do. > 2) Summary view, i.e. to have the samples of each CPU for comparison > next to each other in columns and maybe the histogram view a bit > more compressed (perhaps summary of all CPUs). I agree, the current view is not really optimal. I'll look into this as well. Alexei indicated that he is working on per-cpu variables support. I think that would be extremely useful to drop the hard coded limit of CPUs and turning this sample code into some more generic code. > Anyway, it's sample code people can go with and modify individually. I am interested to turn this code into a more useful tool. Though I think I miss some background information why this code is kept as samples. Obviously, there is the API and ARCH dependency. As long as an API change can reliable be detected I don't see a real show stopper. Maybe I am too naive. Furthermore I expected that trace_preempt_[on|off] wont change that often. > Acked-by: Daniel Borkmann Thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/