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

[Borislav Petkov <bp@amd64.org>]

On Wed, May 30, 2012 at 11:24:41PM +0000, Luck, Tony wrote:
> >         u32 grain;              /* granularity of reported error in bytes */
> > 				   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> >> 			dimm->grain = nr_pages << PAGE_SHIFT;
> 
> I'm not at all sure what we'll see digging into the chipset registers
> like EDAC does - but we do have different granularity when reporting
> via machine check banks.  That's why we have this code:
> 
>                 /*
>                  * Mask the reported address by the reported granularity.
>                  */
>                 if (mce_ser && (m->status & MCI_STATUS_MISCV)) {
>                         u8 shift = MCI_MISC_ADDR_LSB(m->misc);
>                         m->addr >>= shift;
>                         m->addr <<= shift;

That's 64 bytes max, IIRC.

> in mce_read_aux().  In practice right now I think that many errors will
> report with cache line granularity,

Yep.

> while a few (IIRC patrol scrub) will report with page (4K)
> granularity. Linux doesn't really care - they all have to get rounded
> up to page size because we can't take away just one cache line from a
> process.

I'd like to see that :-)

> > @Tony: Can you ensure us that, on Intel memory controllers, the address
> > mask remains constant at module's lifetime, or are there any events that
> > may change it (memory hot-plug, mirror mode changes, interleaving 
> > reconfiguration, ...)?
> 
> I could see different controllers (or even different channels) having
> different setup if you have a system with different size/speed/#ranks
> DIMMs ... most systems today allow almost arbitrary mix & match, and the
> BIOS will decide which interleave modes are possible based on what it
> finds in the slots.  Mirroring imposes more constraints, so you will
> see less crazy options. Hot plug for Linux reduces to just the hot add
> case (as we still don't have a good way to remove DIMM sized chunks of
> memory) ... so I don't see any clever reconfiguration possibilities
> there (when you add memory, all the existing memory had better stay
> where it is, preserving contents).

You're funny :-)

> Perhaps the only option where things might change radically is socket
> migration ... where the constraint is only that the target of the
> migration have >= memory of the source. So you might move from some
> weird configuration with mixed DIMM sizes and thus no interleave, to a
> homogeneous socket with matched DIMMs and full interleave. But from an
> EDAC level, this is a new controller on a new socket ... not a changed
> configuration on an existing socket.

Right, from the frequency of such events happening, it still sounds to
me like the perfect place for the grain value is in sysfs.

Thanks.

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