On Mon, 2009-06-22 at 08:58 -0400, Christoph Hellwig wrote:
> But talking about syscalls the sys_perf_counter_open prototype is
> really ugly - it uses either the pid or cpu argument which is a pretty
> clear indicator it should actually be two sys calls.
Would something like the below be any bett
On Mon, 2009-07-13 at 19:30 +0200, Arnd Bergmann wrote:
> On Monday 13 July 2009, Peter Zijlstra wrote:
> > On Mon, 2009-06-22 at 08:58 -0400, Christoph Hellwig wrote:
> > > But talking about syscalls the sys_perf_counter_open prototype is
> > > really ugly - it uses either the pid or cpu argument
On Monday 13 July 2009, Peter Zijlstra wrote:
> On Mon, 2009-06-22 at 08:58 -0400, Christoph Hellwig wrote:
> > But talking about syscalls the sys_perf_counter_open prototype is
> > really ugly - it uses either the pid or cpu argument which is a pretty
> > clear indicator it should actually be two
On Monday 13 July 2009, Peter Zijlstra wrote:
> On Mon, 2009-07-13 at 19:30 +0200, Arnd Bergmann wrote:
> > > +struct perf_counter_target {
> > > + __u32 id;
> > > + __u64 val;
> > > +};
> >
> > This structure is not compatible between 32 and 64 bit user space o
Corey,
I looked at the patch today.
I am just wondering about a few things:
- it looks like the event table entries for Power 5, 6, 7 all use
the same format. I think it would
simplify things if common types would be put in common for all
Power processors. In libpfm4,
I will be doing t
Yes, I think I could combine those. The only issue is that the tables and
structures are auto-generated for each processor, and the script that generates
them only looks at one at a time, so it doesn't detect commonality. There may
be an easy way to fix this... I'll look into it.
That would r
On Tue, Jul 14, 2009 at 2:58 AM, Corey
Ashford wrote:
> Yes, I think I could combine those. The only issue is that the tables and
> structures are auto-generated for each processor, and the script that
> generates them only looks at one at a time, so it doesn't detect
> commonality. There may be
Sergey,
I suspect that what you are seeing has nothing to do with printf buffering.
The line is flushed out on \n.
What you are seeing is a side effect of monitoring probably lots of
threads + aggregation.
There is no output until a sampling buffer fills up. With
--smpl-entries=1, they fill up q
