From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754611AbbCBTg6 (ORCPT ); Mon, 2 Mar 2015 14:36:58 -0500 Received: from mail-qc0-f179.google.com ([209.85.216.179]:38998 "EHLO mail-qc0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753920AbbCBTg5 (ORCPT ); Mon, 2 Mar 2015 14:36:57 -0500 MIME-Version: 1.0 From: Alexei Starovoitov Date: Mon, 2 Mar 2015 11:36:36 -0800 Message-ID: Subject: Re: [PATCH v2 00/15] tracing: 'hist' triggers To: Steven Rostedt Cc: Tom Zanussi , Masami Hiramatsu , Namhyung Kim , Andi Kleen , LKML , Ingo Molnar , Arnaldo Carvalho de Melo Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 2, 2015 at 11:31 AM, Steven Rostedt wrote: > On Mon, 2 Mar 2015 11:14:54 -0800 > Alexei Starovoitov wrote: > >> I think we both want to see in-kernel aggregation. >> This 'hist' stuff is trying to do counting and even map sorting >> in the kernel, whereas with bpf programs I'm moving >> all of these decisions to user space. >> I understand your desire to avoid any user level scripts >> and do everything via 'cat' and debugfs, but imo that's >> very limiting. I think it's better to do slim user space >> scripting language that can translate to bpf even in >> embedded setups. Then users will be able to aggregate >> whatever they like, whereas with 'hist' approach >> they're limited to simple counters. >> trace_events_trigger.c - 1466 lines - that's quite a bit >> of code that will be rarely used. Kinda goes counter >> to embedded argument. Why add this to kernel >> when bpf programs can do the same on demand? > > At Collab, a lot of people came to me telling me they love the debugfs > system. Because it's everywhere they go. You remove that, you remove > most users (including myself). > > >> Also the arguments about stable ABI apply as well. >> The format of 'hist' file would need to be stable, so will >> be hard to extend it. With bpf programs doing aggregation >> the kernel ABI exposure is much smaller. > > I disagree with this statement. > >> So would you consider working together on adding >> clean bpf+tracepoints infra and corresponding >> user space bits? >> We can have small user space parser/compiler for >> 'hist:keys=common_pid.execname,id.syscall:vals=hitcount' >> strings that will convert it into bpf program and you'll >> be able to use it in embedded setups ? > > Make sure it also works on android. the sad part is that tracing is off on android... so all of tracefs is actually compiled out there... and probably will be if we keep adding rarely used code to it.