This patch fixes the default smpl_entries calculation when using the
v2.0 perfmon kernel code.
We originally saw this problem when running pfmon on a 16 cpu system.
% /usr/bin/pfmon --system-wide -t 2 --short-smpl-periods=16000000
number of entries in sampling buffer is zero
cannot create perfmon context: Invalid argument
cannot create perfmon context: Invalid argument
cannot create perfmon context: Invalid argument
cannot create perfmon context: Invalid argument
...
We found that if we limited the number of cpus by adding --cpu-list=0-6,
it worked. We then discovered that this was related to the locked memory
ulimit. Setting 'ulimit -l unlimited' allowed it to work on this machine.
Here's the problem. In pfmon_compute_smpl_entries() (pfmon/pfmon_util.c),
it attemps to dynamically calculate the default number of smpl_entries
based on the locked memory limit from getrlimit(RLIMIT_MEMLOCK, ...).
But it appears that this was designed with the newer perfmon kernel code
in mind, not the v2.0 code (SUSE SLES10) that we are using. In fact, with
the v2.0 code, locked memory is never used at all, so these calculations
based on locked memory limit are meaningless. This patch reverts pfmon
to using the old method to determine the default smpl_entries for v2.0
kernels only.
Signed-off-by: Tony Ernst <[EMAIL PROTECTED]>
--- pfmon/pfmon/pfmon_util.c 2007-05-01 15:00:56.482141136 -0500
+++ pfmon/pfmon/pfmon_util.c 2007-05-01 15:04:29.593477171 -0500
@@ -1170,6 +1170,12 @@
unsigned long max_entries = 0, orig_smpl_entries = 0;
size_t pfm_avail, memlock_avail, mem_avail, pgsz;
+ if (options.opt_is22 == 0) {
+ if (options.smpl_entries == 0)
+ options.smpl_entries = 2048UL;
+ return 0;
+ }
+
pgsz = getpagesize();
pfm_avail = pfmon_get_perfmon_smpl_mem();
_______________________________________________
perfmon mailing list
[email protected]
http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
