Stephane Eranian <[EMAIL PROTECTED]> writes:
> [...]
>> > [...] AFAIK, there is no single call to stop T1 and wait until it
>> > is completely off the CPU, unless we go through the (internal)
>> > ptrace interface.
>>
>> The utrace code supports this style of thread manipulation better
>> than p
Charles,
On Fri, Dec 14, 2007 at 02:12:17PM -0500, Frank Ch. Eigler wrote:
>
> Stephane Eranian <[EMAIL PROTECTED]> writes:
>
> > [...] AFAIK, there is no single call to stop T1 and wait until it
> > is completely off the CPU, unless we go through the (internal)
> > ptrace interface.
>
> The u
Stephane Eranian <[EMAIL PROTECTED]> writes:
> [...] AFAIK, there is no single call to stop T1 and wait until it
> is completely off the CPU, unless we go through the (internal)
> ptrace interface.
The utrace code supports this style of thread manipulation better
than ptrace.
- FChE
--
To unsu
Hello,
A few weeks back, I mentioned that I would post some
interesting problems that I have encountered while
implementing perfmon and for which I am still looking
for better solutions.
Here is one that I would like to solve right now and
for which I am interested in your comments.
One of the p
From: Stephane Eranian <[EMAIL PROTECTED]>
Date: Mon, 19 Nov 2007 12:53:30 -0800
> In anycase, I would be happy to integrate your sparc64 patches.
I sent these to Philip Mucci late last night, but in the meantime
I finished implementing breakpoint support as well for pfmon.
Let me clean up my di
From: Stephane Eranian <[EMAIL PROTECTED]>
Date: Mon, 19 Nov 2007 14:48:46 -0800
> Looks like we will have to use bytes (u8) instead. This may have some
> performance impact as well. Several bitmaps are used in the context/interrupt
> routines. Even with u8, there is still a problem with the bitm
Paul,
On Tue, Nov 20, 2007 at 08:43:32AM +1100, Paul Mackerras wrote:
> David Miller writes:
>
> > As a result I've found that perfmon2 is quite nice and allows
> > incredibly useful and powerful tools to be written. The syscalls
> > aren't that bad and really I see not reason to block it's incl
David Miller writes:
> As a result I've found that perfmon2 is quite nice and allows
> incredibly useful and powerful tools to be written. The syscalls
> aren't that bad and really I see not reason to block it's inclusion.
>
> I rescind all of my earlier objections, let's merge this soon :-)
St
David,
On Mon, Nov 19, 2007 at 05:08:43AM -0800, David Miller wrote:
>
> Instead of blabbering further about this topic, I decided to put my
> code where my mouth is and spent the weekend porting the perfmon2
> kernel bits, and the user bits (libpfm and pfmon) to sparc64.
>
I appreciate your ef
Instead of blabbering further about this topic, I decided to put my
code where my mouth is and spent the weekend porting the perfmon2
kernel bits, and the user bits (libpfm and pfmon) to sparc64.
As a result I've found that perfmon2 is quite nice and allows
incredibly useful and powerful tools to
Hello,
On Wed, Nov 14, 2007 at 08:20:22PM -0800, dean gaudet wrote:
> On Wed, 14 Nov 2007, Andi Kleen wrote:
>
> > Later a syscall might be needed with event multiplexing, but that seems
> > more like a far away non essential feature.
>
> actually multiplexing is the main feature i am in need of
Herbert Xu <[EMAIL PROTECTED]> writes:
> That's strong static typing. Netlink is 90% strong static
> typing plus 10% strong dynamic typing. That is, it'll tell
> you at run-time if you give it the wrong netlink attribute.
Well it tells you EINVAL no matter what is wrong.
That's roughly similar
Hi,
On Thu, Nov 15, 2007 at 12:11:10PM +1100, Paul Mackerras wrote:
> David Miller writes:
>
> > From: Paul Mackerras <[EMAIL PROTECTED]>
> > Date: Thu, 15 Nov 2007 10:12:22 +1100
> >
> > > *I* never had a problem with a few extra system calls. I don't
> > > understand why you (apparently) do.
Paul Mackerras <[EMAIL PROTECTED]> wrote:
>
> Well you must mean something different by "strong typing" from the
> rest of us. Strong typing means that the compiler can check that you
> have passed in the correct types of arguments, but the compiler
> doesn't have any visibility into what structur
On Thu, 15 Nov 2007, Paul Mackerras wrote:
> dean gaudet writes:
>
> > actually multiplexing is the main feature i am in need of. there are an
> > insufficient number of counters (even on k8 with 4 counters) to do
> > complete stall accounting or to get a general overview of L1d/L1i/L2 cache
>
dean gaudet writes:
> actually multiplexing is the main feature i am in need of. there are an
> insufficient number of counters (even on k8 with 4 counters) to do
> complete stall accounting or to get a general overview of L1d/L1i/L2 cache
> hit rates, average miss latency, time spent in variou
On Wed, 14 Nov 2007, Andi Kleen wrote:
> Later a syscall might be needed with event multiplexing, but that seems
> more like a far away non essential feature.
actually multiplexing is the main feature i am in need of. there are an
insufficient number of counters (even on k8 with 4 counters) to d
David Miller writes:
> From: Paul Mackerras <[EMAIL PROTECTED]>
> Date: Thu, 15 Nov 2007 12:11:10 +1100
>
> > The third (hard to extend cleanly) is a good point, and is a valid
> > criticism of the current set of perfmon2 system calls, I think.
> > However, the goal of being able to extend the in
From: Paul Mackerras <[EMAIL PROTECTED]>
Date: Thu, 15 Nov 2007 12:11:10 +1100
> The third (hard to extend cleanly) is a good point, and is a valid
> criticism of the current set of perfmon2 system calls, I think.
> However, the goal of being able to extend the interface tends to be in
> oppositio
David Miller writes:
> From: Paul Mackerras <[EMAIL PROTECTED]>
> Date: Thu, 15 Nov 2007 10:12:22 +1100
>
> > *I* never had a problem with a few extra system calls. I don't
> > understand why you (apparently) do.
>
> We're stuck with them forever, they are hard to version and extend
> cleanly.
Andi Kleen writes:
> > This only works when counting (not sampling) and only for self-monitoring.
>
> It works for global monitoring too.
How would you provide access to the counters of another process?
Through an extension to ptrace perhaps?
Paul.
-
To unsubscribe from this list: send the line
Andi,
On Wed, Nov 14, 2007 at 03:24:11PM +0100, Andi Kleen wrote:
> On Wed, Nov 14, 2007 at 05:09:09AM -0800, Stephane Eranian wrote:
> >
> > Partially true. The file descriptor becomes really useful when you sample.
> > You leverage the file descriptor to receive notifications of counter
> > ov
On Thursday 15 November 2007 09:56, Chuck Ebbert wrote:
> On 11/14/2007 05:17 AM, Nick Piggin wrote:
> > But in general, for special files, I guess the response is usually
> > some structured data (that is not visible at the syscall layer).
> > So I don't see a big problem to have a similarly arbit
From: Paul Mackerras <[EMAIL PROTECTED]>
Date: Thu, 15 Nov 2007 10:12:22 +1100
> *I* never had a problem with a few extra system calls. I don't
> understand why you (apparently) do.
We're stuck with them forever, they are hard to version and extend
cleanly.
Those are my main objections.
-
To u
David Miller writes:
> From: Paul Mackerras <[EMAIL PROTECTED]>
> Date: Thu, 15 Nov 2007 08:50:22 +1100
>
> > I'd prefer to have a transaction() system call like I suggested to
> > Nick rather than overloading read() like this.
>
> So much for getting rid of the extra system calls...
*I* never
From: Paul Mackerras <[EMAIL PROTECTED]>
Date: Thu, 15 Nov 2007 08:50:22 +1100
> I'd prefer to have a transaction() system call like I suggested to
> Nick rather than overloading read() like this.
So much for getting rid of the extra system calls...
-
To unsubscribe from this list: send the line
On 11/14/2007 05:17 AM, Nick Piggin wrote:
>
> But in general, for special files, I guess the response is usually
> some structured data (that is not visible at the syscall layer).
> So I don't see a big problem to have a similarly arbitrarily
> structured request.
>
>
IOW, an ioctl.
-
To unsub
On Thursday 15 November 2007 08:30, Paul Mackerras wrote:
> Nick Piggin writes:
> > What I really mean is a readv-like syscall, but one that also
> > vectorises the file offset. Maybe this is useful enough as a generic
> > syscall that also helps Paul's example...
>
> I've sometimes thought it woul
David Miller writes:
> > You're suggesting that the behaviour of a read() should depend on what
> > was in the buffer before the read? Gack! Surely you have better
> > taste than that?
>
> Absolutely that's what I mean, it's atomic and gives you exactly what
> you need.
>
> I see nothing wrong
Nick Piggin writes:
> What I really mean is a readv-like syscall, but one that also
> vectorises the file offset. Maybe this is useful enough as a generic
> syscall that also helps Paul's example...
I've sometimes thought it would be useful to have a "transaction"
system call that is like a write
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Wed, 14 Nov 2007 13:38:38 +0100
> At least for x86 and I suspect some 1other architectures we don't
> initially need a syscall at all for this. There is an instruction
> RDPMC who can read a performance counter just fine. It is also much
> faster and gene
> BTW, isn't rdpmc only enable for ring 0 on linux ? I remember a patch
> to disable it, dunno if it has been applied.
Obviously -- without a system call to set up performance counters it
would be fairly useless. But of course once such system calls are in
they should be able to trigger the bit fo
On Wed, 14 Nov 2007 at 10:44 +, Will Cohen wrote:
> Andi Kleen wrote:
>
> >>One approach does not prevent the other. Assuming you allow cr4.pce, then
> >>nothing prevents
> >>a self-monitoring thread from reading the counters directly. You'll just
> >>get the
> >>lower 32-bit of it. So if y
On Wed, Nov 14, 2007 at 10:44:20AM -0500, William Cohen wrote:
> Andi Kleen wrote:
>
> >>One approach does not prevent the other. Assuming you allow cr4.pce, then
> >>nothing prevents
> >>a self-monitoring thread from reading the counters directly. You'll just
> >>get the
> >>lower 32-bit of it
Andi Kleen wrote:
One approach does not prevent the other. Assuming you allow cr4.pce, then
nothing prevents
a self-monitoring thread from reading the counters directly. You'll just get the
lower 32-bit of it. So if you read frequently enough, you should not have a
problem.
Hmm? RDPMC is 64b
On Wed, Nov 14, 2007 at 06:13:42AM -0800, Stephane Eranian wrote:
> > At least for x86 and I suspect some 1other architectures we don't
> > initially need a syscall at all for this. There is an instruction
> > RDPMC who can read a performance counter just fine. It is also much
> > faster and genera
On Wed, Nov 14, 2007 at 05:09:09AM -0800, Stephane Eranian wrote:
>
> Partially true. The file descriptor becomes really useful when you sample.
> You leverage the file descriptor to receive notifications of counter overflows
> and full sampling buffer. You extract notification messages via read()
Andi,
On Wed, Nov 14, 2007 at 01:38:38PM +0100, Andi Kleen wrote:
> Christoph Hellwig <[EMAIL PROTECTED]> writes:
> >
> > I've done this a gazillion times before, so maybe instead of beeing a lazy
> > bastard you could look up mailinglist archive. It's not like this is the
> > first discussion of
On Wed, Nov 14, 2007 at 10:44:56PM +1100, Paul Mackerras wrote:
> David Miller writes:
>
> > This is my impression too, all of the things being done with
> > a slew of system calls would be better served by real special
> > files and appropriate fops.
>
> Special files and fops really only work
Hello,
On Wed, Nov 14, 2007 at 10:39:24PM +1100, Paul Mackerras wrote:
> Christoph Hellwig writes:
>
> > int pfm_read_pmds(int fd, pfarg_pmd_t *pmds, int n)
> >
> > This is basically a read(2) (or for other syscalls a write) on something
> > else than the file descriptor provided to the system
Andi,
On Wed, Nov 14, 2007 at 03:07:02AM +0100, Andi Kleen wrote:
>
> [dropped all these bouncing email lists. Adding closed lists to public
> cc lists is just a bad idea]
>
Just want to make sure perfmon2 users participate in this discussion.
> > int
> > main(int argc, char **argv)
> > {
> >
Christoph Hellwig <[EMAIL PROTECTED]> writes:
>
> I've done this a gazillion times before, so maybe instead of beeing a lazy
> bastard you could look up mailinglist archive. It's not like this is the
> first discussion of perfmon. But to get start look at the systems calls,
> many of them are bea
On Wednesday 14 November 2007 23:07, David Miller wrote:
> From: Paul Mackerras <[EMAIL PROTECTED]>
> Date: Wed, 14 Nov 2007 23:03:24 +1100
>
> > You're suggesting that the behaviour of a read() should depend on what
> > was in the buffer before the read? Gack! Surely you have better
> > taste th
On Wednesday 14 November 2007 22:58, David Miller wrote:
> From: Nick Piggin <[EMAIL PROTECTED]>
> Date: Wed, 14 Nov 2007 10:49:48 +1100
>
> > On Wednesday 14 November 2007 22:44, Paul Mackerras wrote:
> > > David Miller writes:
> > > > This is my impression too, all of the things being done with
>
From: Paul Mackerras <[EMAIL PROTECTED]>
Date: Wed, 14 Nov 2007 23:03:24 +1100
> You're suggesting that the behaviour of a read() should depend on what
> was in the buffer before the read? Gack! Surely you have better
> taste than that?
Absolutely that's what I mean, it's atomic and gives you e
David Miller writes:
> The same way we handle some of the multicast "getsockopt()"
> calls. The parameters passed in are both inputs and outputs.
For a read??!!!
> For the above example:
>
> struct pmd_info {
> int *pmd_numbers;
> u64 *pmd_values;
>
From: Nick Piggin <[EMAIL PROTECTED]>
Date: Wed, 14 Nov 2007 10:49:48 +1100
> On Wednesday 14 November 2007 22:44, Paul Mackerras wrote:
> > David Miller writes:
> > > This is my impression too, all of the things being done with
> > > a slew of system calls would be better served by real special
>
From: Paul Mackerras <[EMAIL PROTECTED]>
Date: Wed, 14 Nov 2007 22:44:56 +1100
> For instance, if you have something that kind-of looks like
>
> read_pmds(int n, int *pmd_numbers, u64 *pmd_values);
>
> where the caller supplies an array of PMD numbers and the function
> returns their value
From: Paul Mackerras <[EMAIL PROTECTED]>
Date: Wed, 14 Nov 2007 22:39:24 +1100
> No it's not basically a read(). It's more like a request/reply
> interface, which a read()/write() interface doesn't handle very well.
Yes it can, see my other reply.
-
To unsubscribe from this list: send the line "
On Wednesday 14 November 2007 22:44, Paul Mackerras wrote:
> David Miller writes:
> > This is my impression too, all of the things being done with
> > a slew of system calls would be better served by real special
> > files and appropriate fops.
>
> Special files and fops really only work well if yo
Christoph Hellwig writes:
> int pfm_read_pmds(int fd, pfarg_pmd_t *pmds, int n)
>
> This is basically a read(2) (or for other syscalls a write) on something
> else than the file descriptor provided to the system call.
No it's not basically a read(). It's more like a request/reply
interface, w
David Miller writes:
> This is my impression too, all of the things being done with
> a slew of system calls would be better served by real special
> files and appropriate fops.
Special files and fops really only work well if you can coerce the
interface into one where data flows predominantly on
Ok, I just got 4 freakin' bounces from all of these subscriber only
perfmon etc. mailing lists.
Please remove those lists from the CC: as it's pointless for those of
us not on the lists to participate if those lists can't even see the
feedback we are giving.
-
To unsubscribe from this list: send
From: Christoph Hellwig <[EMAIL PROTECTED]>
Date: Wed, 14 Nov 2007 11:00:09 +
> I've done this a gazillion times before, so maybe instead of beeing a lazy
> bastard you could look up mailinglist archive. It's not like this is the
> first discussion of perfmon. But to get start look at the sy
On Wed, Nov 14, 2007 at 09:43:02PM +1100, Paul Mackerras wrote:
> Christoph Hellwig writes:
>
> > Mine for example. The whole userspace interface is just on crack,
> > and the code is full of complexities aswell.
>
> Could you give some _technical_ details of what you don't like?
I've done this
Christoph Hellwig writes:
> Mine for example. The whole userspace interface is just on crack,
> and the code is full of complexities aswell.
Could you give some _technical_ details of what you don't like?
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
On Wed, Nov 14, 2007 at 06:24:36PM +1100, Paul Mackerras wrote:
> Whose sentiment?
Mine for example. The whole userspace interface is just on crack,
and the code is full of complexities aswell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Wed, 14 Nov 2007 18:24:36 +1100 Paul Mackerras <[EMAIL PROTECTED]> wrote:
> Andrew Morton writes:
>
> > I was hoping that after the round of release-and-review which Stephane,
> > Andi and I did about twelve months ago that we were on track to merge the
> > perfmon codebase as-offered. But no
Andrew Morton writes:
> I was hoping that after the round of release-and-review which Stephane,
> Andi and I did about twelve months ago that we were on track to merge the
> perfmon codebase as-offered. But now it turns out that the sentiment is
> that the code simply has too many bells-and-whist
[dropped all these bouncing email lists. Adding closed lists to public
cc lists is just a bad idea]
> int
> main(int argc, char **argv)
> {
> int ctx_fd;
> pfarg_pmd_t pd[1];
> pfarg_pmc_t pc[1];
> pfarg_ctx_t ctx;
> pfarg_load_t load_args;
>
> memset(&ctx, 0,
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 methods
That is hard to believe.
But let's go for it temporarily for the argument.
Can you instead p
Hi Andi,
pfmon is a single tool and fairly low level, the HPC folks don't use
it so much because it isn't parallel aware and is meant for power-
users. It is not representative of the tools used in HPC at all. Our
community uses tools built on the infrastructure provided by libpfm
and PAPI
Andi,
On Tue, Nov 13, 2007 at 11:25:34PM +0100, Andi Kleen wrote:
> On Tue, Nov 13, 2007 at 02:22:34PM -0800, Stephane Eranian wrote:
> > Andi,
> > On Tue, Nov 13, 2007 at 10:50:56PM +0100, Andi Kleen wrote:
> > > > Yes, horribly more complicated because of locking issues within perfmon.
> > > > A
What about investing some effort to do a proper performance counter
infrastructure or turning the mess perfom is into one instead of this
useless rant? Code is not getting any better by your complain ccing
gazillions of useless list.
-
To unsubscribe from this list: send the line "unsubscribe li
On Tue, Nov 13, 2007 at 02:22:34PM -0800, Stephane Eranian wrote:
> Andi,
> On Tue, Nov 13, 2007 at 10:50:56PM +0100, Andi Kleen wrote:
> > > Yes, horribly more complicated because of locking issues within perfmon.
> > > As soon as you expose a file descriptor, you need some locking to prevent
> >
Andi,
On Tue, Nov 13, 2007 at 10:50:56PM +0100, Andi Kleen wrote:
> > Yes, horribly more complicated because of locking issues within perfmon.
> > As soon as you expose a file descriptor, you need some locking to prevent
> > multiple user threads (malicious or not) to compete to access the PMU stat
> Yes, horribly more complicated because of locking issues within perfmon.
> As soon as you expose a file descriptor, you need some locking to prevent
> multiple user threads (malicious or not) to compete to access the PMU state.
Why do you need the file descriptor?
One of the main problems with
Andi.
On Tue, Nov 13, 2007 at 10:29:02PM +0100, Andi Kleen wrote:
> On Tue, Nov 13, 2007 at 01:13:45PM -0800, Stephane Eranian wrote:
> > Oprofile does not setup the PMU interrupt. It builds on top of the NMI
> > watchdog
> > setup.
>
> Oprofile works without the NMI watchdog too, but it just ha
On Tue, Nov 13, 2007 at 01:33:13PM -0800, Stephane Eranian wrote:
> I think I understand your concerns. I will work on this. I think it is
> possible to
> refactor. It will certainly be painful (for me), but I think it can be done
> within
> some reasonable delay. Of course, it would be help if y
Greg,
On Tue, Nov 13, 2007 at 10:59:24AM -0800, Greg KH wrote:
> On Tue, Nov 13, 2007 at 10:47:45AM -0800, Philip Mucci wrote:
> > Hi folks,
> >
> > Well, I can say the mood here at supercomputing'07 is pretty somber in
> > regards to the latest exchange of messages regarding the perfmon patches.
On Tue, Nov 13, 2007 at 01:13:45PM -0800, Stephane Eranian wrote:
> Oprofile does not setup the PMU interrupt. It builds on top of the NMI
> watchdog
> setup.
Oprofile works without the NMI watchdog too, but it just happens to be another
NMI user.
> It uses the register_die() mechanism,
Not co
Will,
On Tue, Nov 13, 2007 at 01:33:55PM -0500, William Cohen wrote:
>
> The oprofile module can setup a handler for PMU interrupts. This is done in
> archi/x86/oprofile/nmi_int:nmi_cpu_setup(). Other modules could do the
> same. However, it bumps what ever was using the nmi/pmu off, then rest
> In the past I suggested that it might be useful to have a version of
> perfmon2 that only set up the perfmon on a global basis. That would allow
Context switch is imho the main differentiating feature of perfmon
over oprofile. Not sure it makes sense to take that one out.
I don't think the
> He speaks for quite a few people - they have serious need for this feature
Most likely they have serious need for a very small subset of perfmon2.
The point of my proposal was to get this very small subset in quickly.
Phil, how many of the command line options of pfmon do you
actually use? How
On Tue, Nov 13, 2007 at 12:07:28PM -0800, Andrew Morton wrote:
>
> So. If what I am saying is correct then the best course of action would be
> for Stephane to help us all to understand what these features are and why
> we need them. The ideal way in which to do this is
>
> [patch] perfmon: cor
On Tue, 13 Nov 2007 10:59:24 -0800 Greg KH <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 13, 2007 at 10:47:45AM -0800, Philip Mucci wrote:
> > Hi folks,
> >
> > Well, I can say the mood here at supercomputing'07 is pretty somber in
> > regards to the latest exchange of messages regarding the perfmon p
Hi folks,
Well, I can say the mood here at supercomputing'07 is pretty somber
in regards to the latest exchange of messages regarding the perfmon
patches. Our community has been the largest user of both the PerfCtr
and the Perfmon patches, the former being regularly installed by
vendors a
On Tue, Nov 13, 2007 at 10:47:45AM -0800, Philip Mucci wrote:
> Hi folks,
>
> Well, I can say the mood here at supercomputing'07 is pretty somber in
> regards to the latest exchange of messages regarding the perfmon patches.
"somber"?
Why?
We (a number of the kernel developers) want to see the
Stephane Eranian wrote:
Hello,
On Tue, Nov 13, 2007 at 10:35:11AM -0500, William Cohen wrote:
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 s
Hello,
On Tue, Nov 13, 2007 at 10:35:11AM -0500, William Cohen wrote:
> 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 somet
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 support
to context switch state and initialize counters in a basic way
81 matches
Mail list logo
