From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756886AbbA2Sza (ORCPT ); Thu, 29 Jan 2015 13:55:30 -0500 Received: from mail-qg0-f43.google.com ([209.85.192.43]:37408 "EHLO mail-qg0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753492AbbA2Sz2 (ORCPT ); Thu, 29 Jan 2015 13:55:28 -0500 MIME-Version: 1.0 From: Alexei Starovoitov Date: Thu, 29 Jan 2015 10:55:07 -0800 Message-ID: Subject: Re: [PATCH v2 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls To: Namhyung Kim Cc: Steven Rostedt , Ingo Molnar , Arnaldo Carvalho de Melo , Jiri Olsa , Masami Hiramatsu , Linux API , Network Development , LKML 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 Thu, Jan 29, 2015 at 4:35 AM, Namhyung Kim wrote: >>> Right. I think bpf programs belong to a user process but events are >>> global resource. Maybe you also need to consider attaching bpf >>> program via perf (ioctl?) interface.. >> >> yes. I did. Please see my reply to Masami. >> ioctl only works for tracepoints. > > What was the problem of kprobes then? :) Looks like I misread the logic of attaching a filter via perf ioctl. Looking at it again it seems to be a major change in design: Instead of adding into ftrace_raw_* helpers, I would add to perf_trace_* helpers which are very stack heavy because of 'pt_regs' Ex: perf_trace_kfree_skb() is using 224 bytes of stack whereas ftrace_raw_event_kfree_skb() only 80. which doesn't help in my quest for lowest overhead. And the discussion about soft- and auto- enable/disable becomes meaningless, since there is no such things when it goes through perf events. I guess it means no hooks through tracefs... Anyway, I'll hook it up and see which way is cleaner.