Stephane,
On Wed, May 02, 2007 at 03:20:21PM -0700, Stephane Eranian wrote:
> Tony,
>
> On Wed, May 02, 2007 at 12:31:36PM -0500, Tony Ernst wrote:
> > 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
>
> I found some references to RLIMIT_MEMLOCK, but I think the current code
> is broken is that it does not seem to update RLIMIT_MEMLOCK.cur when the
> allocation is successful. This is gone from v2.4 and also the v2.0
> compatbility layer embedded in it for IA-64.
>
> I am willing to take your pfmon patch but I would also welcome a kernel
> patch to correctly manage RLIMIT_MEMLOCK for v2.0.
I'm afraid I don't understand this comment. You don't want to update
RLIMIT_MEMLOCK.rlim_cur when you allocate. rlim_cur is your current
(soft) limit. It's not a running total of how much is left. Did you
mean mm->locked_vm? locked_vm is being updated in your latest patchset.
Thanks,
Tony
>
> Thanks for the patch.
>
> > --- 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/
>
> --
>
> -Stephane
_______________________________________________
perfmon mailing list
[email protected]
http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
