On Thursday 26 July 2007 09:02:22 am Stephane Eranian wrote:
> Hello,
>
> I have released another version of the perfmon new code base package.
> This version of the kernel patch is relative to 2.6.22. Sorry for
> the delay but there was some traveling on my part + a lot
> of patches to integrate + a lot of important changes.
>
> This new kernel patch includes the following new features and
> bug fixes:
> - co-exist with Oprofile on x86_64 and i386. Both subsystems
> are mutually exclusive. You either run a session in one or
> the other. But the kernel can be compiled with both subsystems
> enabled. No changes required to the user level Oprofile code.
>
> - rename perfmon_gen_ia32.c to perfmon_intel_arch.c
>
> - perfmon_intel_arch.c supports architectural perfmon v1 and v2
> (as defined in IA-32 manual Vol 3b dated May 2007)
>
> - perfmon_core.c renamed perfmon_intel_core.c
>
> - reworked register mapping for perfmon_core.c to be compatible
> with V1 and V2. The Intel Core PMU is backward compatible with
> V1 and V2. it is important to ensure that an application written
> to know only about architectural perfmon can work unmodified on
> all PMU that implement architectural perfmon. Generic counters
> are in range 0-16, fixed counters are in range 16-31. PEBS is
> added as PMC17.
>
> - renamed pfm_msg_t to pfarg_msg_t to match argument naming. The
> structure layout was also modified.
>
> - simplify API by having only one bitmap size for all PMD bitmaps
> shared with the user level. Deal with IA-64 v2.0 compatibility
> separately. This is is incompatible with earlier v2.xx version,
> recompilation is necessary.
>
> - created an arch specific header files (asm-*/perfmon_const.h) to
> specify the per-arch maximum number of PMCs and PMDs supported
> (including SW PMU registers).
>
> - remove ability to have the SW-maintained 64-bit counters remapped
> at the user level (PFM_FL_MAP_SETS). This feature was not really
> used. this features was not available on all archs as it required
> the ability to read a hw counter directly at the user level.
>
> - remove the ability to provide a explicit set number as the next set
> to go to PFM_SETFL_EXPL_NEXT. This feature was not really used. Now,
> this is a simple round-robin following the set order. The data
> structure pfarg_setdesc has been changed accordingly.
>
> - improved overflow-based set switching by leveraging the fact that
> monitoring is already stopped
>
> - on x86, connect perfmon to the basic PMU register allocator used by
> the NMI watchdog and Oprofile. PMU registers are now acquired on first
> perfmon context creation. They are released when the last perfmon
> context is destroyed.
>
> - simplification of active NMI watchdog detection. Now in common
> i386/x86_64 perfmon code.
>
> - On Intel Core (and architectural perfmon v2), we do not use/expose the
> new GLOBAL_* PMU MSR due to sharing issues with NMI watchdog.
>
> - Certain MIPS systems have cache aliasing problems with the sampling buffer.
> Provide compile time option to enable two possible workarounds: explicit
> flushing on write in the buffer, force a mich bigger page alignment for
> the buffer in vmalloc(). Patches provided by Kevin Cernekee.
>
> - PowerPC updates, Power5 udpates, Cell Processor code support.
> Patches provided by Kevin Corry (IBM)
>
> - AMD Barcelona support, general code cleanup, improved debug messages
> in syscall code. Patches provided by Robert Richter (AMD). AMD IBS
> support not yet included.
>
> - enable Pentium II support by Vince Weaver (Cornell)
>
> - sysfs /sys stale entries removal
>
> A lot of changes went into this release. A particular thank you to Kevin
> and Robert for providing bug fixes and cleanups to the common code base.
> I would also like to thank David Rientjes (Google) for his detailed code
> review. I have integrated almost all of his remarks in this release.
> Special thanks to Andi Kleen for his code review and his constructive
> remarks.
>
> IMPORTANT: This release is not backward compatible with previous releases.
> You need to recompile and/or adjust your apps. Old IA-64 v2.0, applications
> are supported with no recompilation/modification.
>
> I have also released a new libpfm, libpfm-3.2-070725, with lots of
> changes. Here are some of the most important ones:
> - reflect ALL API changes for the v2.6 perfmon interface
> including syscall number changes
> - Cray Blackwidow support by Steve Kaufmann (Cray Inc)
> - PowerPC updates by Kevin Corry (IBM)
> - some MIPS updates by Manoj Ekbote
> - simplify config.mk by compiling all known targets for each architecture
> - man pages updates by Steve Kaufmann
> - examples updates especially self.c to avoid compiler optimizations
> - check for CPU revisions (A,B,C,D,E) on AMD64 event mask support
> - enable Pentium II Deschutes by Vince Weaver (Cornell)
>
> IMPORTANT: this version of the library ONLY works with 2.6.22.
>
> Also a new version of pfmon, pfmon-3.2-070725, with lots of changes,including:
> - update to v2.6 kernel API and latest libpfm
> - cleanup breakpoint API
> - added x86 software breakpoint code (not yet functional)
> - merge pfmon_util_i386.c and pfmon_util_x86_64.c into pfmon_util_x86.c
> - simplify config.mk by compiling all known targets for each architecture
>
> IMPORTANT: you need libpfm-3.2-070725 with this release of pfmon
>
> In terms of mainline integration, the kernel package includes a base.diff
> patch which contains a several infrastructure changes:
>
> - all arch: remove TIF_NOTIFY_RESUME
> - mips : add smp_call_function_single()
> - x86_64 : add AMD64 (family 16) MSR definitions for PMU
> - i386 : add cpu_has_arch_perfmon macro
> - i386 : perfctr-watchdog.c don't BUG_ON() when msr is unknown
> - i386 : oprofile/nmi_int.c do model_shutdown() only once
>
> Unfortunately, this patches grew again in this release but mostly due to the
> removal of the TIF_NOTIFY_RESUME patch which has been submitted to LKML.
> The simple PMU register allocator in perfctr-watchdog.c still needs a lot of
> work. Bjorn Steinbrink has been working on this.
>
> You can get the package and very detailed changelogs our the web site:
>
> http://perfmon2.sf.net
>
> Enjoy,
>
Back during some of the previous discussion of this set of patches:
>On Mon, Jun 04, 2007 at 08:13:41AM -0700, David Rientjes wrote:
>> On Tue, 29 May 2007, Stephane Eranian wrote:
snipped..
>> > +++ linux-2.6.22/drivers/oprofile/oprofile_files.c 2007-05-29 03:24:14.000000000 -0700
>> > +
>> > +static ssize_t implementation(struct file * file, char __user * buf, size_t count, loff_t * offset)
>> > +{
>> > + return oprofilefs_str_to_user(oprofile_ops.implementation, buf, count, offset);
>> > +}
>> > +
>> > +
>> > +static struct file_operations implementation_fops = {
>> > + .read = implementation,
>> > +};
>> > +
>> > void oprofile_create_files(struct super_block * sb, struct dentry * root)
>> > {
>> > oprofilefs_create_file(sb, root, "enable", &enable_fops);
>> > @@ -127,6 +137,7 @@ void oprofile_create_files(struct super_
>> > oprofilefs_create_ulong(sb, root, "buffer_watershed", &fs_buffer_watershed);
>> > oprofilefs_create_ulong(sb, root, "cpu_buffer_size", &fs_cpu_buffer_size);
>> > oprofilefs_create_file(sb, root, "cpu_type", &cpu_type_fops);
>> > + oprofilefs_create_file(sb, root, "implementation", &implementation_fops);
>> > oprofilefs_create_file(sb, root, "backtrace_depth", &depth_fops);
>> > oprofilefs_create_file(sb, root, "pointer_size", &pointer_size_fops);
>> > oprofile_create_stats_files(sb, root);
>>
>> The commentary for how to interpret this new file is lacking; it appears
>> as though it will return "timer", "oprofile", or "nmi_timer" for existing
>> i386 subsystems and "perfmon2" with this addition. This should be
>> documented.
>>
>> It isn't set generically in oprofile_arch_init() for other architectures.
>
>This modification of oprofile was one to allow the user level oprofile daemon
>to determine which kernel "implementation" of oprofile it is running on. This
>way tool could transparently run on existing Oprofile and also on systems
>with both perfmon and Oprofile.
>
>Andi suggested that during a transition period, we let Oprofile and perfmon
>co-exist as opposed to moving Oprofile on top of perfmon right away. I think this
>is a good suggestion. As a consequence, I will remove this Oprofile extension.
It looks to me like you were saying you would remove this extension to the
OProfile file system (/dev/oprofile/implementation).
However, it looks like it has made it into the mainline kernel code. As David
pointed out, the value isn't initialized for architectures other than i386. As
a result you get a kernel crash (at least on PPC) with the following commands.
opcontrol --init
cat /dev/oprofile/implementation
Kevin Corry is working on a patch but until that makes it out people may want
to be a little careful with this...
Bob Nelson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
