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
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.
Afre you
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
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
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
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 utrace code
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
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
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
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
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
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
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 shape
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
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
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
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
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,
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
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
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
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
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.
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
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
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
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 would
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 one
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 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
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
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 the
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
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
get back
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, allowing
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 counters
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 counters
-
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 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
ndi 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, Andi Kleen wrote:
>
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
; 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, Andi Kleen wrote:
Later a syscall might be needed with event multiplexing
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
1 - 100 of 202 matches
Mail list logo
