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
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
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
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 :-)
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
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
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
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
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 :-)
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 inclusion.
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
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
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
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
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)
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
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 structures are
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.
We're
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 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. there
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
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
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
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
>
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
>
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
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
> >
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
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
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
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
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
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
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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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:
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
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
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
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, 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
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:
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 a
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
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 body
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 one
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,
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
files
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
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 you can
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 values (and
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
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;
int
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
a slew of
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 than that?
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 beasts
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)
{
int
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 call.
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 well if
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 perfmon.
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()
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 generally
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
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. So if you read
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 you read
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 for
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 generally
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 or gross
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 +
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 had a
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
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 arbitrarily
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 unsubscribe
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 would be
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
overflows
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
1 - 100 of 148 matches
Mail list logo
