From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754644AbbJUMGb (ORCPT ); Wed, 21 Oct 2015 08:06:31 -0400 Received: from szxga02-in.huawei.com ([119.145.14.65]:31661 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751982AbbJUMG3 (ORCPT ); Wed, 21 Oct 2015 08:06:29 -0400 Message-ID: <56277F29.3000704@huawei.com> Date: Wed, 21 Oct 2015 20:03:53 +0800 From: "Wangnan (F)" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Peter Zijlstra CC: Alexei Starovoitov , Kaixu Xia , , , , , , , , , , Subject: Re: [PATCH V5 1/1] bpf: control events stored in PERF_EVENT_ARRAY maps trace data output when perf sampling References: <1445325735-121694-1-git-send-email-xiakaixu@huawei.com> <1445325735-121694-2-git-send-email-xiakaixu@huawei.com> <5626C5CE.8080809@plumgrid.com> <20151021091254.GF2881@worktop.programming.kicks-ass.net> <56277844.9090201@huawei.com> <20151021115630.GO17308@twins.programming.kicks-ass.net> In-Reply-To: <20151021115630.GO17308@twins.programming.kicks-ass.net> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.111.66.109] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2015/10/21 19:56, Peter Zijlstra wrote: > On Wed, Oct 21, 2015 at 07:34:28PM +0800, Wangnan (F) wrote: >>> If you want to actually disable the event: pmu->stop() will make it >>> stop, and you can restart using pmu->start().xiezuo >> I also prefer totally disabling event because our goal is to reduce >> sampling overhead as mush as possible. However, events in perf is >> CPU bounded, one event in perf cmdline becomes multiple 'perf_event' >> in kernel in multi-core system. Disabling/enabling events on all CPUs >> by a BPF program a hard task due to racing, NMI, ... > But eBPF perf events must already be local afaik. Look at the > constraints perf_event_read_local() places on the events. I think soft disabling/enabling is free of this constraint, because technically speaking a soft-disabled perf event is still running. What we want to disable is only sampling action to avoid being overwhelming by sampling and reduce the overhead which output those unneeded sampling data to perf.data. I don't care whether the PMU counter is stopped or still running too much. Even if it still generate interrupts I think it should be acceptable because interruption handling can be fast. Thank you.