From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752787AbdKHP5r (ORCPT ); Wed, 8 Nov 2017 10:57:47 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37612 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752677AbdKHP5p (ORCPT ); Wed, 8 Nov 2017 10:57:45 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com CF38FC04AC64 Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jolsa@redhat.com Date: Wed, 8 Nov 2017 16:57:41 +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: <20171108155741.GA12627@krava> References: <20171106092305.GA16382@krava> <20171108141522.GA6320@krava> <20171108151218.GA11018@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.31]); Wed, 08 Nov 2017 15:57:45 +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:51:10AM -0800, Milind Chabbi wrote: > On Wed, Nov 8, 2017 at 7:12 AM, Jiri Olsa wrote: > > > > 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 > > > Why is this not a concern for modify_user_hw_breakpoint() function? I don't know ;-) jirka