From: Robert R. <rob...@am...> - 2011-11-16 21:42:17
|
On 15.11.11 18:07:23, Andreas Krebbel wrote: > On 11/15/2011 10:31 AM, Robert Richter wrote: > > On 02.11.11 11:10:06, Andreas Krebbel wrote: > >> > >> The 'kernel' and 'user' flags can now be used to filter for samples. > > > > Does this work for both modes (TIMER and HWSAMPLING)? > > No. This only works for HWSAMPLING. The daemon may not set the flags then in timer mode. I can't remember how it is implemented in x86, but either we need to check the flags and throw an -EINVAL or at least write back the actually used values so that the daemon/user may read it. > There are two compatibility aspects involved: > > 1.) With the current patch the existing OProfile user space will not work with hardware > sampling being enabled in the machine since the tools do not know about the > s390x/basic_mode_sampling_v1 cpu type. So with that regard the patch breaks compatibilty. > But as I understand it this would be resolved by adding the backward compatibility module > parameter which forces the module to always return "timer" as cpu type. So this would be a > non-issue then. > > 2.) The new filesystem entries for the event interface co-exist with the old filesystem. > The user can still use the echo ... > /dev/oprofile/hwsampling/... commands he is used to. > So with the current patch the module stays compatible to the existing interface. Can't we drop /dev/oprofile/hwsampling/ and only support it with "timer" forced by a kernel parameter to be backward compatible with older oprofile daemons? Would make live easier. > >> + oprofilefs_create_ulong(sb, dir, "enabled", &counter_config.enabled); > >> + oprofilefs_create_file(sb, dir, "event", &hwsampler_fops); > >> + oprofilefs_create_ulong(sb, dir, "count", &counter_config.count); > >> + oprofilefs_create_ulong(sb, dir, "unit_mask", &counter_config.unit_mask); > >> + oprofilefs_create_ulong(sb, dir, "kernel", &counter_config.kernel); > >> + oprofilefs_create_ulong(sb, dir, "user", &counter_config.user); > >> + oprofilefs_create_ulong(sb, dir, "extra", &counter_config.extra); > > > > What is the reason for creating entries that are unused? > > We are somewhat abusing the oprofile event file system in order to allow configuring and > enabling of the hwsampling facility. That's the reason not all of the files are actually > used. However, the user space seems to expect their existence. Providing dummy files helps > avoiding special cases in the user space tools by making it think we have a full blown > event interface. If possible I would rather prefer to not have it at all, but if the daemon requires it anyway we should at least only allow certain values to be used. The kernel should check this. In the end this would be only unit_mask and extra which should be set to 0 or so. A check is required also for kernel and user flags, so it shouldn't be a big deal to implement this for all. > >> + ops->cpu_type = "s390x/basic_mode_sampling_v1"; > > > > Why are you using "s390x" instead of "s390"? Also, the long name looks > > ugly. Any better idea? > > The hardware sampling is only available in z/Architecture mode and s390x stands for a > S/390 machine running in that mode. > > Mmmh I've no really better idea for the long name. The sampling mode is called "basic mode > sampling" in the hardware documentation and I thought that name should match it. And I've > appended a '_v1' in case that mode will be changed in the future. Usually we take <arch>/<model> where <arch> is as uname reports it, but this is not always consistent. Doing so it would be "s390/systemz", but not sure if this would fit here. Various supported features could be detected by the existence of file/directories in oprofilefs. This could be used if there is a new version or so of hardware sampling. -Robert -- Advanced Micro Devices, Inc. Operating System Research Center |