All of lore.kernel.org
 help / color / mirror / Atom feed
From: Don Zickus <dzickus@redhat.com>
To: Stephane Eranian <eranian@hpl.hp.com>
Cc: linux-kernel@vger.kernel.org, ak@suse.de,
	oprofile-list@lists.sourceforge.net, perfmon@napali.hpl.hp.com
Subject: Re: [patch 8/8] Add abilty to enable/disable nmi watchdog from sysfs
Date: Wed, 10 May 2006 15:06:01 -0400	[thread overview]
Message-ID: <20060510190601.GM16561@redhat.com> (raw)
In-Reply-To: <20060510150357.GO21833@frankl.hpl.hp.com>

On Wed, May 10, 2006 at 08:03:57AM -0700, Stephane Eranian wrote:
> Don,
> 
> On Wed, May 10, 2006 at 10:59:53AM -0400, Don Zickus wrote:
> > > 
> > > This means you can at runtime enable/disbale nmi_watchdog, i.e., reserve
> > > some performance counters on the fly. This gets complicated because now
> > > the perfmon subsystem (and probably oprofile) cannot check register
> > > availability when they are first initialized. Basically each time,
> > > the /sys entry is modified, they would have to scan the list of available
> > > performance counters. I don't know exactly when Oprofile does this checking.
> > > For perfmon, this is done only once, when the PMU description table is loaded.
> 
> > How often did you plan on enabling/disabling the nmi_watchdog?  My
> > understanding was you disable nmi_watchdog, run oprofile/perfmon,
> > re-enable nmi_watchdog.  I guess I don't understand what type of funky
> > scenarios you are dealing with.  
> > 
> I thought that part of the exercise was to allow oprofile/perfmon and nmi_watchdog
> to work simultaneously, i.e., don't disable watchdog when you monitor. Leave watchdog
> on and have oprofile/perfmon run with fewer counters. The alternative would be to do
> what you say: disbale nmi, monitor, re-enable nmi.

It was and the patch allows one to run the monitor and the nmi_watchdog at
the same time.  I guess I am confused to what your original concern
was.  

> 
> > > 
> > > Also something that I did not see in this code is the error detection in
> > > case enable_lapic_nmi_watchdog() fails. Oprofile runs on all CPUs or none.
> > > Perfmon lets you monitor on subsets on CPUs. In case NMI was disabled and
> > > a monitoring session was active on some CPUs. The enable_lapic_nmi_watchdog()
> > > will fail on some CPUs. How is that handled?
> > 
> > It's not.  In fact I wouldn't know what to do in such situations.  Is it
> > really wrong to only have a subset of cpus being monitored by the
> > nmi_watchdog?  This seems to be wandering into the area where the user is
> > looking to do something complicated (profiling a subset of cpus) and as
> > such might be expected to make sure the nmi_watchdog is properly enabled
> > on all cpus when they are done.
> > 
> On larger machines (think NUMA-style), it does not always make sense to monitor all CPUs.

That makes sense.  Thinking about it, it probably wouldn't be too hard to
add code to try and re-scan the cpus and enable those nmi_watchdogs that
were disabled during your monitoring.  But you would have to manually do
this once you were done testing. 

Cheers,
Don

      reply	other threads:[~2006-05-10 19:06 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-09 20:50 [patch 0/8] [RFC PATCH] nmi watchdog: x86 32/64 cleanup dzickus
2006-05-09 20:50 ` [patch 1/8] nmi watchdog header cleanup dzickus
2006-05-09 20:50 ` [patch 2/8] Add performance counter reservation framework for UP kernels dzickus
2006-05-09 20:50 ` [patch 3/8] Utilize performance counter reservation framework in oprofile dzickus
2006-05-09 20:50 ` [patch 4/8] Add SMP support on x86_64 to reservation framework dzickus
2006-05-09 21:42   ` Andi Kleen
2006-05-09 20:50 ` [patch 5/8] Add SMP support on i386 " dzickus
2006-05-22 17:31   ` Markus Armbruster
2006-05-22 17:55     ` Don Zickus
2006-05-09 20:50 ` [patch 6/8] Cleanup NMI interrupt path dzickus
2006-05-09 20:50 ` [patch 7/8] Remove un/set_nmi_callback and reserve/release_lapic_nmi functions dzickus
2006-05-09 20:50 ` [patch 8/8] Add abilty to enable/disable nmi watchdog from sysfs dzickus
2006-05-09 21:37   ` Andi Kleen
2006-05-10  9:10   ` Stephane Eranian
2006-05-10  9:28     ` Andi Kleen
2006-05-10 14:59     ` Don Zickus
2006-05-10 15:03       ` Stephane Eranian
2006-05-10 19:06         ` Don Zickus [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060510190601.GM16561@redhat.com \
    --to=dzickus@redhat.com \
    --cc=ak@suse.de \
    --cc=eranian@hpl.hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oprofile-list@lists.sourceforge.net \
    --cc=perfmon@napali.hpl.hp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.