Re: [PATCH] RAS: Add a tracepoint for reporting memory controllerevents

[Borislav Petkov]

On Thu, May 31, 2012 at 03:04:55PM -0300, Mauro Carvalho Chehab wrote:
> The tracepoint approach is proposed as a way to replace dmesg, so,
> dmesg is not an option.

Of course it is an option: userspace parses dmesg and gets grain value.

> Sysfs nodes for address grain won't work, as, on MCA, the grain is
> only known when an error is generated, and it is valid only together
> with an error report.

This is only true on Intel.

> Having the _same_ field exported either in sysfs or via the trace,
> depending if the grain is dynamic or if it is global-wide is a very
> crappy API, as the same information would be provided to userspace via
> different API's, with is insane.

No, what is crappy is "punishing" other drivers just because you need
grain for your drivers.

Ask Steven how expensive are 4 bytes in a tracepoint and what it means
wasting space in the ring buffer.

[ â ]

> > Again, only on those drivers which have dynamic grain. Other drivers
> > which keep outputting 'x' (and 'x' doesn't change) on every tracepoint
> > invocation don't need to output it all in the tracepoint.
> 
> So what? If only one type of granularity applies to all addresses, the
> information provided to userspace won't be wrong.

The argument is not whether it is wrong or not - it is about wasting
space unnecessarily where it counts. Write this down and hammer it to
your forehead so that you can finally understand it!

<remove some random unrelated blubber>

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/