linux-kernel - Re: [PATCH] RAS: Add a tracepoint for reporting memory controller events

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: <1338495092.13348.419.camel@gandalf.stny.rr.com>
Date:	Thu, 31 May 2012 16:11:32 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Borislav Petkov <bp@...64.org>
Cc:	Mauro Carvalho Chehab <mchehab@...hat.com>,
	"Luck, Tony" <tony.luck@...el.com>,
	Linux Edac Mailing List <linux-edac@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Aristeu Rozanski <arozansk@...hat.com>,
	Doug Thompson <norsk5@...oo.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH] RAS: Add a tracepoint for reporting memory controller
 events

On Thu, 2012-05-31 at 21:42 +0200, Borislav Petkov wrote:
> On Thu, May 31, 2012 at 03:32:52PM -0400, Steven Rostedt wrote:
> > Just so I understand your point. You are saying things like grain that
> > don't change but are different per device, should just be in some sysfs
> > file somewhere, and things that are dynamic during runtime should go
> > into the tracepoint.
> 
> Right, for the majority of edac drivers, grain is a static value
> assigned once per driver initialization.
> 
> Then there are other drivers which report different grain per error.
> 
> Now, all I'm saying is, the static ones should report grain once when
> the driver inits in dmesg or in sysfs and _not_ report grain in each
> tracepoint invocation - we don't want to waste space in the ring buffer
> for information which never or only very seldom changes.
> 
> For the drivers where grain is per error, they report it in the
> tracepoint (and only they!) as part of the driver-specific char string.
> 
> This way all is fair and no space in the ring buffer gets wasted.
> 
> Makes sense?

Sure, but how noisy is EDAC? Does it actually fill up the ring buffers?

-- Steve



--
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/