linux-kernel - Re: [PATCH -tip, final] perf, x86: Add hw_watchdog_set

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110705114437.GC15654@elte.hu>
Date:	Tue, 5 Jul 2011 13:44:37 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Cyrill Gorcunov <gorcunov@...il.com>
Cc:	Don Zickus <dzickus@...hat.com>,
	Stephane Eranian <eranian@...gle.com>,
	Lin Ming <ming.m.lin@...el.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -tip, final] perf, x86: Add hw_watchdog_set_attr() in a
 sake of nmi-watchdog on P4


* Cyrill Gorcunov <gorcunov@...il.com> wrote:

> On Tue, Jul 05, 2011 at 01:20:02PM +0200, Ingo Molnar wrote:
> > 
> > * Cyrill Gorcunov <gorcunov@...il.com> wrote:
> > 
> > > On Tue, Jul 05, 2011 at 12:59:59PM +0200, Ingo Molnar wrote:
> > > ...
> > > > 
> > > > are 'non-sleeping ticks' non-halted cycles - i.e. cycles that 
> > > > always count with CPU frequency and can thus be used for periodic 
> > > > frequencies?
> > > 
> > > Yes, I think so (btw, as far as I remember oprofile does the same 
> > > 'threshold' gaming for nmi-watchdog).
> > 
> > But the NMI watchdog does not need a constant frequency event - it 
> > can use unhalted cycles just fine. Why does it need unhalted cycles 
> > on P4?
> > 
> 
> Ingo, the main problem there is not halted or unhalted events but rather
> inability of p4 architecture to move events between counters, with core
> or nehalem you can (if constraints allow) simply move nmi-watchdog event
> to another free counter and assign cpu cycles to a free slot. With p4 the
> situation is radically different -- every event has a number of contraints
> and once nmi-watchdog armed (it could be halted or unhaled event, whatever)
> ESCR/CCCR/counter registers tuple borrowed forever and we need to find out
> some different non-intersected ESCR/CCCR/counter tuple to count cpu-cycles
> in a sake of perf utility purpose. That is why this assignments done in
> a such weird way -- just to be able to run nmi-watchdog and cpu-cycles
> simultaneously.
> 
> Probably I miss something and you mean something completely different?

What i am missing is that you have not pointed out the *core problem* 
you are fixing and it's not obvious from the changelog either!

That the P4 has weird event constraints is not a problem users care 
about...

What 'bad thing' happens in practice without this patch, what 
limitations arise in perf or in the NMI watchdog? Does it lock up? 
Does it not work? Does 'perf top' get confused?

Conversely, what 'good thing' happens if the patch is applied and are 
there any limitations left?

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/