Hi,
> Regarding OS information --
>
> One thing I'd like to see in oprofile and other profiling tools is the
> ability to collect info. about important low-level OS events. In addition
> to recording context switches, it will soon (as in yesterday) be necessary
> to record other OS events such as changes in power management state such
> as changing clock rate or duty cycle, voltages, etc. I say necessary because
> the meaning of "cycles" will change from moment to moment. P4s and Opterons
> have this capability now and multi-core chips will soon require that the OS
> be active. I don't know how to present this information to the user/performance
> analyst, but I know that we will have to. While we're at it, I'm willing
> to argue that "events" such as delays/contention at kernel locks, and other
> sources of low-level delay, get reported using the same mechanisms as hardware
> counter events.
Comming version of LKST (linux kernel state tracer) will
have some performance monitoring facilities.
For examples, spin lock busy waiting time, context switches,
runqueue length, wait queue length, and so on.
You can trace all system call events by the LKST.
The development of the performance monitoring facilities
of LKST is partly supported by IPA (Information-Technology
Promotion Agency, Japan).
Regards,
Hiro
From: Rob Fowler <rjf@...>
Subject: HPCA workshop and oprofile on clusters
Date: Thu, 17 Feb 2005 17:25:27 -0600
Message-ID: <421527E7.6040403@...>
> As one of the organizers/speakers, here are my addenda to Will's message --
>
> > The goal of the workshop was to discuss issues related to performance
> > monitoring. A summary of paper should be coming out of the discussions. There
> > should be postings of the presentations at (but it may take a little while be
> > cause people HPCA11 runs through most of the week):
> >
> > http://lacsi.rice.edu/workshops/hpca11/
>
> I just got back home. Revised versions of the slides will be posted as
> soon as I get permission. Several industrial speakers wanted to make sure
> they've got all the trademarks properly annotated, etc.
>
> Comments regarding Will's comments on my talk:
>
> It's not so much that build processes take so long (They do.) as the fact
> that they're extremely complex, involving thousands of files in hundreds
> of directories, autoconf/automake, and scripts written in sh, m4, perl, and
> python that may be rewriting the source code that eventually gets compiled.
> Also, significant costs are incurred in libraries -- it's unrealistic to
> have to rebuild /usr/lib/* with instrumentation and there may be other
> libraries for which source isn't available. My message was "Tools that don't
> work on work with unmodified (preferably compiled with debugging symbols and
> not stripped) binaries can't compete in this environment."
>
> Regarding OS information --
>
> One thing I'd like to see in oprofile and other profiling tools is the
> ability to collect info. about important low-level OS events. In addition
> to recording context switches, it will soon (as in yesterday) be necessary
> to record other OS events such as changes in power management state such
> as changing clock rate or duty cycle, voltages, etc. I say necessary because
> the meaning of "cycles" will change from moment to moment. P4s and Opterons
> have this capability now and multi-core chips will soon require that the OS
> be active. I don't know how to present this information to the user/performance
> analyst, but I know that we will have to. While we're at it, I'm willing
> to argue that "events" such as delays/contention at kernel locks, and other
> sources of low-level delay, get reported using the same mechanisms as hardware
> counter events.
>
> Regarding our upcoming work with oprofile --
>
> Consider this message an invitation for feedback and help.
>
> In the next couple of months we will be doing what's necessary to get HPCToolkit
> working with oprofile on Linux clusters, including Clustermatic (bproc and
> diskless compute nodes) systems. The first issue is specific to our stuff --
>
> Data translation -- This is a "small matter of programming". For our
> purposes, hacking up a derivative of opreport that includes our
> XMLwriter would suffice. Our data format is essentially S-expressions
> using lean XML syntax. On Tru64, where we don't have access to the
> DCPI source, we use dcpicat to create an object-instruction level profile,
> which we then process with the executable to create the XML-format
> source-line profile. Hence, we're flexible about the details of the
> workflow in the process.
>
> "root" issues -- We can live with having to be root to run opcontrol.
> On a shared cluster this would be done by a batch scheduler that (at
> least partly) runs as root. On other systems, SETUID or sudo can
> be used. What does have to happen, however, is to have all the
> data files moved to some directory owned by the user so down-stream
> analysis can be done in user mode. (See the file system item below.)
> Node-wide analysis is important since we're looking at pieces of parallel
> programs; a lot of the action is in the kernel, shared libraries, and
> communication demons. We also need to know about "parasite" processes.
> In batch mode, the application generally "owns" the node and all actions
> by the system are on behalf of the application. On "shared by friendly
> users working together on a project" platforms
> I think it's OK for a sudo'er to gain a system-wide view. What's not
> acceptable is for the user to leave the demon running forever. A
> "run this job under oprofile" script that's guaranteed to clean up
> on exit would be an acceptable way of doing this.
>
> file system issues -- An alternative to writing in /var/lib/oprofile is
> necessary. Everything for downstream analysis needs to wind up in
> a place specified when the demon is started up. Even on the diskless
> nodes we'll have a net-mounted FS and the script that starts the
> demon on node N would pass in a path like
> "/scratch/this_user/this_job/nodeN" as the destination for files
> collected on this node. Of course, opcontrol (running as root) needs
> to be conservative w.r.t. permissions to write to this destination on
> behalf of the user.
>
> Acceptance -- We'd like to do this once and have as much as possible
> itegrated with the oprofile distribution.
>
> --
> Rob Fowler
> Dept. of Computer Science, MS-132
> Rice University,
> 6100 Main Street
> Houston, TX 77005
> 713 348-5709
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> oprofile-list mailing list
> oprofile-list@...
> https://lists.sourceforge.net/lists/listinfo/oprofile-list
|