[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMmz+Y=95ffwgSbLSXoAPOrdQXVQftZNJFjoH=kjpGkZ2u2LYw@mail.gmail.com>
Date: Mon, 13 Nov 2017 00:02:56 -0800
From: Milind Chabbi <chabbi.milind@...il.com>
To: Jiri Olsa <jolsa@...hat.com>
Cc: Milind Chabbi <chabbi.milind@...il.com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Namhyung Kim <namhyung@...nel.org>,
linux-kernel@...r.kernel.org,
Michael Kerrisk-manpages <mtk.manpages@...il.com>,
linux-man@...r.kernel.org, Michael Ellerman <mpe@...erman.id.au>,
Andi Kleen <ak@...ux.intel.com>,
Kan Liang <kan.liang@...el.com>,
Hari Bathini <hbathini@...ux.vnet.ibm.com>,
Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>,
Jin Yao <yao.jin@...ux.intel.com>
Subject: Re: [PATCH] perf/core: fast breakpoint modification via _IOC_MODIFY_BREAKPOINT
SNIP
On Sun, Nov 12, 2017 at 11:46 PM, Jiri Olsa <jolsa@...hat.com> wrote:
> but you closed fd4 before openning fd5..?
Yes, that is correct. I closed fd4. The reason is by closing fd4, we
are having a total of 3 hardware breakpoints active, but we are making
the software counting in the kernel think that four TYPE_DATA
breakpoints active. The counting should have disallowed us from
creating fd5 as per the following logic in the kernel:
static int __reserve_bp_slot(struct perf_event *bp)
{
....
/* Flexible counters need to keep at least one slot */
if (slots.pinned + (!!slots.flexible) > nr_slots[type])
return -ENOSPC;
....
}
Powered by blists - more mailing lists