Messages in this thread | | | Date | Thu, 27 Nov 2008 19:54:33 +0100 | From | "stephane eranian" <> | Subject | Re: [patch 02/24] perfmon: base code |
| |
Thomas,
On Thu, Nov 27, 2008 at 7:36 PM, Thomas Gleixner <tglx@linutronix.de> wrote: > On Thu, 27 Nov 2008, Andi Kleen wrote: > >> > Well, where is it checked ? Where is checked whether Oprofile runs or not ? >> >> That is done using the perfctr reservation. I saw that somewhere in the >> patchkit. The NMI watchdog uses that too. >> >> > > The Oprofile reservation you see is built on top of the cpumask reservation. >> > > It tries to allocate in one call and atomically ALL the CPUs as this is the way >> > > Oprofile operates. Thus it fails if one perfmon system-wide session or one >> > > perfmon per-thread exists. >> > >> > This only prevents oprofile from starting, but it does neither prevent >> > thread sessions nor does it prevent a perfmon per cpu session on a cpu >> > which was onlined after oprofile started, simply because it's bit is >> > missing in the CPU mask. >> >> The perfctr reservation is global over all CPUs. > > So this mean we manage resources on multiple levels, some bits here > and some bits there and five checks in each code path do get them all. > > Really convincing concept.
That is a different level of resource management: register level.
Both Perfmon and Oprofile can operate with fewer registers than what the hardware actually supports. Take an AMD64 CPU with 4 counters. With the NMI watchdog active, Perfmon or Oprofile will run with only 3. That's better than nothing and is sufficient for many measurments.
| |