From: "Patrick DEMICHEL" <[EMAIL PROTECTED]>
Date: Sat, 17 Nov 2007 18:19:25 +0100
> Yet another noisy linux HPC user
Nobody on this list is interested in discussing this.
Really, the on-topic discussion here is the code and
the technical issues. And we will work on those to
get perfmon2 into s
Yet another noisy linux HPC user
I hope to convince you, lkml developers, to pay more attention to our
HPC performance problems.
I will not try to convince you that our problems are also the problems
of many others users, I hope they will do it directly.
Imagine my company bought an expensive co
On Sat, Nov 17, 2007 at 02:48:45AM +0100, Patrick DEMICHEL wrote:
> Thanks Greg,
>
>but for external people it seems there is lot of people with opposite
> opinions, for sure some are valid and they can be focused on different
> things. But for example this critical topic seems quite not under
On Sat, Nov 17, 2007 at 02:13:13AM +0100, Patrick DEMICHEL wrote:
> Yet another noisy linux HPC user
>
> I hope to convince you, lkml developers, to pay more attention to our HPC
> performance problems.
We do pay attention, and want to help out, we just need either bug
reports of problems that we
On Fri, Nov 16, 2007 at 04:29:05PM -0800, David Miller wrote:
> From: dean gaudet <[EMAIL PROTECTED]>
> Date: Fri, 16 Nov 2007 09:51:08 -0800 (PST)
>
> > On Fri, 16 Nov 2007, Andi Kleen wrote:
> >
> > > I didn't see a clear list.
> >
> > - cross platform extensible API for configuring perf coun
From: dean gaudet <[EMAIL PROTECTED]>
Date: Fri, 16 Nov 2007 09:51:08 -0800 (PST)
> On Fri, 16 Nov 2007, Andi Kleen wrote:
>
> > I didn't see a clear list.
>
> - cross platform extensible API for configuring perf counters
> - support for multiplexed counters
> - support for virtualized 64-bit c
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Fri, 16 Nov 2007 16:15:56 +0100
> Philip Mucci <[EMAIL PROTECTED]> writes:
> > - A feature which was dropped earlier by Stefane (only to satiate
> > LKML), we consider
> > very important. Allowing one tomapping of the kernels view of the
> > PMD's, allowi
Will,
On Fri, Nov 16, 2007 at 12:13:07PM -0500, William Cohen wrote:
> Andi Kleen wrote:
> >On Fri, Nov 16, 2007 at 08:00:56AM -0800, Stephane Eranian wrote:
> >>No, he is talking about something similar to what was in perfctr.
> >>The kernel emulates 64-bit counters in software and that is you
>
Yes it is for everybody. I've been rather questioning if the slow
ways (complicated syscalls) to get the counter information are really
needed.
I suppose by complicated here, your referring to the gather semantics
of the
pfm_read/write_pmds/pmcs calls. Many processors may have 100's of
reg
On Fri, 16 Nov 2007, Andi Kleen wrote:
> I didn't see a clear list.
- cross platform extensible API for configuring perf counters
- support for multiplexed counters
- support for virtualized 64-bit counters
- support for PC and call graph sampling at specific intervals
- support for reading coun
Andi,
On Fri, Nov 16, 2007 at 05:28:13PM +0100, Andi Kleen wrote:
> On Fri, Nov 16, 2007 at 08:00:56AM -0800, Stephane Eranian wrote:
> > No, he is talking about something similar to what was in perfctr.
> > The kernel emulates 64-bit counters in software and that is you
> > get back when you read
Andi Kleen wrote:
On Fri, Nov 16, 2007 at 08:00:56AM -0800, Stephane Eranian wrote:
No, he is talking about something similar to what was in perfctr.
The kernel emulates 64-bit counters in software and that is you
get back when you read the counters. If you read via RDPMC, you
get 40 bits. To re
On Fri, Nov 16, 2007 at 08:00:56AM -0800, Stephane Eranian wrote:
> No, he is talking about something similar to what was in perfctr.
> The kernel emulates 64-bit counters in software and that is you
> get back when you read the counters. If you read via RDPMC, you
> get 40 bits. To reconstruct the
Andi,
On Fri, Nov 16, 2007 at 04:15:56PM +0100, Andi Kleen wrote:
> My impression so far is that you're not quite sure what you want,
> otherwise you would be more concrete.
>
> > - A feature which was dropped earlier by Stefane (only to satiate
> > LKML), we consider
> > very important. Allowing
Philip Mucci <[EMAIL PROTECTED]> writes:
>
> Yes, although this has been done before. You've got the list below in
> the previous
> emails which should be considered the absolute minimum.
I didn't see a clear list.
My impression so far is that you're not quite sure what you want,
otherwise you w
Just getting back to this now that SC07 is finally over...
On Nov 13, 2007, at 5:52 PM, Andi Kleen wrote:
On Tue, Nov 13, 2007 at 04:28:52PM -0800, Philip Mucci wrote:
I know you don't want to hear this, but we actually use all of the
features of perfmon, because a) we wanted to use the best m
2007 11:20 PM
> To: Andi Kleen
> Cc: papi list; OSPAT devel; Greg KH; Perfmon; linux-
> [EMAIL PROTECTED]; Christoph Hellwig; Paul Mackerras; Andrew Morton;
> [EMAIL PROTECTED]; Philip Mucci
> Subject: Re: [perfmon2] [perfmon] Re: perfmon2 merge news
>
> On Wed, 14 Nov 2007,
On Tue, Nov 13, 2007 at 10:32:39AM -0800, Stephane Eranian wrote:
> It would obvisouly cause a lot of troubles to existing perfmon libraries and
> applications (e.g. PAPI). It would also be fairly tricky to do because you'd
> have to make sure that in the beginning, you leave enough flexiblity suc
Hello,
On Tue, Nov 13, 2007 at 04:17:18PM +0100, Robert Richter wrote:
> On 10.11.07 21:32:39, Andi Kleen wrote:
> > It would be really good to extract a core perfmon and start with
> > that and then add stuff as it makes sense.
> >
> > e.g. core perfmon could be something simple like just suppor
19 matches
Mail list logo
