RE: [perfmon] Re: quick overview of the perfmon2 interface

Would you want Stephane to guard the extended
functionalities with tunables or something to
Disable their regular use and herd enterprise
Tools into a standard mold... yet allow R&D to
Move on by enabling the extentions?



Just crippling flexibility/cutting functionality
is like removing words out of a dictionary to
prevent people from thinking different.

It would restrict the R&D mindset, and new ideas.
The field hasn't grown yet to a stable mature form.
It is just beginning: profiling, monitoring, tuning,
compilers, JIT...

Flexibility is/was needed because:
- Tools need to port to Perfmon with min cost.
- Ability to support novel R&D ideas.
- Ability to support growth beyond just PMU data
- Allows early data aggregation
- Allow OS data correlated to PMU

What standardization adds:
- Coordinated access to PMU rssources from all tools
- All tools/formats etc all plug into the same OS framework.
- The interface gets ported across multiple platforms.
- The functionality is rich for all (fast data transfers,
multiplexing, system vs thead, etc.)

Dan-

> -----Original Message-----
> From: perfmon-bounces@xxxxxxxxxxxxxxxxx [mailto:perfmon-
> bounces@xxxxxxxxxxxxxxxxx] On Behalf Of Andrew Morton
> Sent: Thursday, December 22, 2005 5:47 AM
> To: Truong, Dan
> Cc: Eranian, Stephane; perfmon@xxxxxxxxxxxxxxxxx; linux-
> ia64@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; perfctr-
> devel@xxxxxxxxxxxxxxxxxxxxx
> Subject: Re: [perfmon] Re: quick overview of the perfmon2 interface
>
> "Truong, Dan" <dan.truong@xxxxxx> wrote:
> >
> > The PMU is becoming a standard commodity. Once Perfmon is
> > "the" Linux interface, all the tools can align on it and
> > coexist, push their R&D forward, and more importantly become
> > fully productized for businesses usage.
> >
>
> The apparently-extreme flexibility of the perfmon interfaces would
tend to
> militate against that, actually. It'd become better productised if it
had
> one interface and stuck to it.
>
> (I haven't processed Stephane's reply yet - will get there)
>
> _______________________________________________
> perfmon mailing list
> perfmon@xxxxxxxxxxxxxxxx
> http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
-
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/

Relevant Pages

  • Re: INSPECT and TRAILING syntax
    ... adding new syntax is a POST-2002 development. ... '02 Standard was that it was simply "TOO BIG". ... COULD already be accomplished and did the language really need them. ... the syntax for that functionality is pretty straightforward -- adds ...
    (comp.lang.cobol)
  • Re: Clunky C cleanup code
    ... some 'portability' for functionality. ... The C-Standard is not the ... the program reports successful termination. ...
    (comp.lang.c)
  • Re: Is C99 the final C? (some suggestions)
    ... > As to the likelihood of either feature making it into the C standard: ... Probably true, but your suggestion is also infinitely less ambitious, ... My suggestion is more like "restrict" in C99 which adds functionality ... compatibility with C89. ...
    (comp.lang.c)
  • Re: Use of internal functionaliy in use case
    ... Any functionality that is unique to the application and is ... [However, for complex applications that have lots of subsystems, it may ... The trivial use case is Packet Processor send packet ... "authenticate via MAC standard XYZ".) ...
    (comp.object)