From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752659AbdKHPMY (ORCPT ); Wed, 8 Nov 2017 10:12:24 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39168 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751370AbdKHPMW (ORCPT ); Wed, 8 Nov 2017 10:12:22 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8898C6A7DE Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jolsa@redhat.com Date: Wed, 8 Nov 2017 16:12:18 +0100 From: Jiri Olsa To: Milind Chabbi Cc: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Alexander Shishkin , Namhyung Kim , linux-kernel@vger.kernel.org, Michael Kerrisk-manpages , linux-man@vger.kernel.org, Michael Ellerman , Andi Kleen , Kan Liang , Hari Bathini , Sukadev Bhattiprolu , Jin Yao Subject: Re: [PATCH] perf/core: fast breakpoint modification via _IOC_MODIFY_BREAKPOINT Message-ID: <20171108151218.GA11018@krava> References: <20171106092305.GA16382@krava> <20171108141522.GA6320@krava> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 08 Nov 2017 15:12:22 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 08, 2017 at 07:02:22AM -0800, Milind Chabbi wrote: > On Wed, Nov 8, 2017 at 6:15 AM, Jiri Olsa wrote: > > On Mon, Nov 06, 2017 at 07:04:40AM -0800, Milind Chabbi wrote: > >> Hi Jirka, > >> > >> I see the tabs in my sent email, do you have suggestions on how best to > >> send this patch so that the tabs are preserved by the email client? > >> Can anybody else also check if they received with/without tabs? > >> > >> release_bp_slot/reserve_bp_slot majic is not necessary since > >> _IOC_MODIFY_BREAKPOINT ioctl modifies an already registered breakpoint > >> without affecting the count of breakpoints active. > > > > but AFAICS you allow to change the breakpoint type (bp_type) > > and slot counts are based on the breakpoint type > > > > jirka > > Jirka, > I am not able to fully understand your concern. > Can you point to a code file and line related to your observation? > The patch is modeled after the existing modify_user_hw_breakpoint() function > present in events/hw_breakpoint.c; don't you see this problem in that code? the reserve_bp_slot/release_bp_slot functions manage counts for current breakpoints based on its type those counts are cumulated in here: static DEFINE_PER_CPU(struct bp_cpuinfo, bp_cpuinfo[TYPE_MAX]); you allow to change the breakpoint type, so I'd expect to see some code that release slot count for old type and take new one (if it's available) jirka