lkml.org 
[lkml]   [2012]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] RAS: Add a tracepoint for reporting memory controller events
From
Date
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





\
 
 \ /
  Last update: 2012-05-31 22:01    [W:0.333 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site