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

[Steven Rostedt]

On Thu, 2012-05-31 at 19:13 +0200, Borislav Petkov wrote:

> > 	- No other userspace API provides it;
> 
> Yes, it should.
> 
> > 	- The granularity is a property of the per-error address;
> 
> Not necessarily, as it is shown above.
> 
> > 	- There are well-known cases where the address grain changes are
> > 	  dynamically filled by the error registers (MCA arch on Intel).
> 
> Ok.
> 
> > So, the memory error tracepoint is the proper place to store it, as it is
> > the place where the address and the other memory error information is
> > reported to userspace.
> 
> Yes, but not as a separate field but in driver_detail _only_ on those
> drivers where grain is dynamic. The remaining ones simply don't output
> it all because they have done so in dmesg or sysfs.
> 
> > Also, converting the grain to a string, as you proposed would require
> > at least 26 bytes to store "grain: 0xdeadbeef:deadbeef", while putting
> > it as a u64 will consume only 8 bytes.
> 
> 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. Their
> tracepoint records shouldn't be inflated for no reason.

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.

Correct?

-- Steve



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