Re: [patch 0/3] [Announcement] Performance Counters for Linux
- From: Paul Mackerras <paulus@xxxxxxxxx>
- Date: Fri, 5 Dec 2008 20:10:13 +1100
Ingo Molnar writes:
* Paul Mackerras <paulus@xxxxxxxxx> wrote:[...]
Isn't it two separate read() calls to read the two counters? If so,
the only way the two values are actually going to correspond to the
same point in time is if the task being monitored is stopped. In which
case the monitoring task needs to use ptrace or something similar in
order to make sure that the monitored task is actually stopped.
It doesnt matter in practice.
Can I ask - and this is a real question, I'm not being sarcastic - is
that statement made with substantial serious experience in performance
analysis behind it, or is it just an intuition?
I will happily admit that I am not a great expert on performance
analysis with years of experience. But I have taken a bit of a look
at what people with that sort of experience do, and I don't think they
would agree with your "doesn't matter" statement.
Such kind of 'group system call facility' has been suggested several
times in the past - but ... never got anywhere because system calls are
cheap enough, it really does not count in practice.
It could be implemented, and note that because our code uses a proper
Linux file descriptor abstraction, such a sys_read_fds() facility would
help _other_ applications as well, not just performance counters.
But it brings complications: demultiplexing of error conditions on
individual counters is a real pain with any compound abstraction. We very
consciously went with the 'one fd, one object, one counter' design.
And I think that is the fundamental flaw. On the machines I am
familiar with, the performance counters as not separate things that
can individually and independently be assigned to count one thing or
another.
Rather, what the hardware provides is ONE performance monitor unit,
which the OS can context-switch between tasks. The performance
monitor unit has several counters that can be assigned (within limits)
to count various aspects of the performance of the code being
executed. That is why, for instance, if you ask for the counters to
be frozen when one of them overflows, they all get frozen at that
point.
And that's how the hardware is designed because that's how the people
that do performance analysis want to do their measurements. This idea
of splitting things up into separate counters that look independent
but aren't is just going to cause unnecessary complications and
difficulties.
Paul.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: [patch 0/3] [Announcement] Performance Counters for Linux
- From: Ingo Molnar
- Re: [patch 0/3] [Announcement] Performance Counters for Linux
- References:
- [patch 0/3] [Announcement] Performance Counters for Linux
- From: Thomas Gleixner
- Re: [patch 0/3] [Announcement] Performance Counters for Linux
- From: Paul Mackerras
- Re: [patch 0/3] [Announcement] Performance Counters for Linux
- From: Ingo Molnar
- Re: [patch 0/3] [Announcement] Performance Counters for Linux
- From: Paul Mackerras
- Re: [patch 0/3] [Announcement] Performance Counters for Linux
- From: Ingo Molnar
- [patch 0/3] [Announcement] Performance Counters for Linux
- Prev by Date: Re: MSI changes in .28
- Next by Date: [PATCH] EXPORTFS: Don't return NULL from fh_to_dentry()/fh_to_parent()
- Previous by thread: Re: [patch 0/3] [Announcement] Performance Counters for Linux
- Next by thread: Re: [patch 0/3] [Announcement] Performance Counters for Linux
- Index(es):
Relevant Pages
|