On Fri, Jul 31, 2015 at 12:42:06AM -0400, Vince Weaver wrote:
> On Thu, 11 Jun 2015, Peter Zijlstra wrote:
>
> > Right, I had a peek earlier at how fasync worked but came away confused.
> >
> > Today I seem to have had better luck. Installing fasync allocates memory
> > and sets filp->f_flags |=
On Fri, Jul 31, 2015 at 12:42:06AM -0400, Vince Weaver wrote:
On Thu, 11 Jun 2015, Peter Zijlstra wrote:
Right, I had a peek earlier at how fasync worked but came away confused.
Today I seem to have had better luck. Installing fasync allocates memory
and sets filp-f_flags |= FASYNC,
On Thu, 11 Jun 2015, Peter Zijlstra wrote:
> Right, I had a peek earlier at how fasync worked but came away confused.
>
> Today I seem to have had better luck. Installing fasync allocates memory
> and sets filp->f_flags |= FASYNC, which upon the demise of the file
> descriptor ensures the
On Thu, 11 Jun 2015, Peter Zijlstra wrote:
Right, I had a peek earlier at how fasync worked but came away confused.
Today I seem to have had better luck. Installing fasync allocates memory
and sets filp-f_flags |= FASYNC, which upon the demise of the file
descriptor ensures the allocation
On Thu, 2015-06-11 at 00:30 -0400, Vince Weaver wrote:
> On Fri, 29 May 2015, Ingo Molnar wrote:
>
> > * Vince Weaver wrote:
>
> > > If we inherit events, we inherit the signal state but not the fasync
> > > state, so
> > > overflows in inherited children will never trigger the signal
On Thu, 2015-06-11 at 00:30 -0400, Vince Weaver wrote:
On Fri, 29 May 2015, Ingo Molnar wrote:
* Vince Weaver vincent.wea...@maine.edu wrote:
If we inherit events, we inherit the signal state but not the fasync
state, so
overflows in inherited children will never trigger the
On Fri, 29 May 2015, Ingo Molnar wrote:
> * Vince Weaver wrote:
> > If we inherit events, we inherit the signal state but not the fasync state,
> > so
> > overflows in inherited children will never trigger the signal handler.
> >
> > Signed-off-by: Vince Weaver
> >
> > diff --git
On Fri, 29 May 2015, Ingo Molnar wrote:
* Vince Weaver vincent.wea...@maine.edu wrote:
If we inherit events, we inherit the signal state but not the fasync state,
so
overflows in inherited children will never trigger the signal handler.
Signed-off-by: Vince Weaver
On Thu, 28 May 2015, Peter Zijlstra wrote:
> What could maybe work -- I'd have to check the code -- is open a
> per-task-per-cpu counter for every cpu. Those we could inherit -- if we
> currently allow it I'm not sure of.
yes, that seems to work. It's a bit of a pain having to juggle so many
* Vince Weaver wrote:
> We're trying to get self-monitoring multi-threaded sampling working in PAPI.
> Fun times.
>
> Is this even possible?
>
> Ideally in your parent thread you could perf_event_open() with inherit set.
> Then your program (say an OpenMP program) would do its thing and
* Vince Weaver vincent.wea...@maine.edu wrote:
We're trying to get self-monitoring multi-threaded sampling working in PAPI.
Fun times.
Is this even possible?
Ideally in your parent thread you could perf_event_open() with inherit set.
Then your program (say an OpenMP program) would
On Thu, 28 May 2015, Peter Zijlstra wrote:
What could maybe work -- I'd have to check the code -- is open a
per-task-per-cpu counter for every cpu. Those we could inherit -- if we
currently allow it I'm not sure of.
yes, that seems to work. It's a bit of a pain having to juggle so many
On Thu, 2015-05-28 at 15:06 -0400, Vince Weaver wrote:
> We're trying to get self-monitoring multi-threaded sampling working in
> PAPI. Fun times.
>
> Is this even possible?
>
> Ideally in your parent thread you could perf_event_open() with
> inherit set. Then your program (say an OpenMP
We're trying to get self-monitoring multi-threaded sampling working in
PAPI. Fun times.
Is this even possible?
Ideally in your parent thread you could perf_event_open() with
inherit set. Then your program (say an OpenMP program) would do its thing
and all of the samples would get written
We're trying to get self-monitoring multi-threaded sampling working in
PAPI. Fun times.
Is this even possible?
Ideally in your parent thread you could perf_event_open() with
inherit set. Then your program (say an OpenMP program) would do its thing
and all of the samples would get written
On Thu, 2015-05-28 at 15:06 -0400, Vince Weaver wrote:
We're trying to get self-monitoring multi-threaded sampling working in
PAPI. Fun times.
Is this even possible?
Ideally in your parent thread you could perf_event_open() with
inherit set. Then your program (say an OpenMP program)
16 matches
Mail list logo
