Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Robert Richter <rrichter@marvell.com>
To:     Mauro Carvalho Chehab <mchehab@kernel.org>
CC:     Borislav Petkov <bp@alien8.de>, Tony Luck <tony.luck@intel.com>,
        "James Morse" <james.morse@arm.com>,
        "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 06/19] EDAC, mc: Remove per layer counters
Thread-Topic: [PATCH 06/19] EDAC, mc: Remove per layer counters
Thread-Index: AQHVf6jU3Hq1HIO940WaZOfHTRxydKdVQUmAgAS/3YA=
Date:   Mon, 14 Oct 2019 11:12:23 +0000
Message-ID: <20191014111215.f5wyed33ilppfopg@rric.localdomain>
References: <20191010202418.25098-1-rrichter@marvell.com>
 <20191010202418.25098-7-rrichter@marvell.com>
 <20191011074031.699396df@coco.lan>
In-Reply-To: <20191011074031.699396df@coco.lan>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [31.208.96.227]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 613c4445-5726-4e54-1dd3-08d750976328
x-ms-traffictypediagnostic: MN2PR18MB2399:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <MN2PR18MB2399851D8ED78929D6817C5BD9900@MN2PR18MB2399.namprd18.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01901B3451
x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(4636009)(39850400004)(396003)(376002)(346002)(136003)(366004)(199004)(189003)(4326008)(305945005)(7736002)(6436002)(446003)(6246003)(2906002)(966005)(229853002)(478600001)(3846002)(6512007)(9686003)(6116002)(6306002)(8936002)(86362001)(486006)(81156014)(8676002)(81166006)(11346002)(71190400001)(71200400001)(256004)(476003)(1076003)(66476007)(66556008)(64756008)(66446008)(52116002)(102836004)(99286004)(5660300002)(54906003)(66946007)(316002)(25786009)(66066001)(14454004)(76176011)(6916009)(186003)(386003)(26005)(6506007)(53546011)(6486002);DIR:OUT;SFP:1101;SCL:1;SRVR:MN2PR18MB2399;H:MN2PR18MB3408.namprd18.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1;
received-spf: None (protection.outlook.com: marvell.com does not designate
 permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: cRyHqW+wF/ksVaaFgYw1UKtlNYZDRpJFBG/oIwqjJ6NMphjEM93oOMIhc+4QD1DdapwKhz7V2j4Mq7o4iELi7Faifj2XOYp9AlhXo0boW+JqaOEAGoezdkvhzxO66KUcdoDPRXrug2B4YcjCQ2wtwvx1qOnmJEXoL3ph49kvtmtjm3pC4pCt0pUKvIbbzC2FP0FO6Qh/KcpJ3fHh4TWM4YTyCQrNVFDamURmUaWDOAtC2G32ekhL5ZD6YeXjC/WNRWc6Vghy/ICxzBQZSxZVZ92eKvAgK3S/0SeL0PwC4ksknuW5VHlWJ5xuORmtj5smoD7EUcCMF0gOBy84F8ZoA8AsdSY9uZYj/nTeGQImPdxHgkEymwCp/GA8Sw7KwXCOjYyBp0WGHz0KLNmdWudRce1MJhtvxDH2X8LOmVlY1mVQCrqQFTbfLqsbgBqVhey1XHg7OWcl4+svdNjEnWwD8A==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-ID: <264E08D05C6B3E47972EEB2C28D8F64E@namprd18.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 613c4445-5726-4e54-1dd3-08d750976328
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2019 11:12:23.1760
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: OvvTQ64qc+izlGOsf4srgY9VqltlFdKkLeSGm4gwdKYEHHGqOigU18lukB9uzDC0g5Ny7GlQz1Szq0u7KGonmQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR18MB2399
X-OriginatorOrg: marvell.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8
 definitions=2019-10-14_07:2019-10-11,2019-10-14 signatures=0
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 11.10.19 07:40:31, Mauro Carvalho Chehab wrote:
> Em Thu, 10 Oct 2019 20:25:16 +0000
> Robert Richter <rrichter@marvell.com> escreveu:
>=20
> > Looking at how mci->{ue,ce}_per_layer[EDAC_MAX_LAYERS] is used, it
> > turns out that only the leaves in the memory hierarchy are consumed
> > (in sysfs), but not the intermediate layers, e.g.:
> >=20
> >  count =3D dimm->mci->ce_per_layer[dimm->mci->n_layers-1][dimm->idx];
> >=20
> > These unused counters only add complexity, remove them. The error
> > counter values are directly stored in struct dimm_info now.
>=20
> Hmm... not sure if this patch is correct. I remember that there are some
> border cases on some drivers (maybe the 3-layer drivers used together
> with RDIMM memory controllers?) where some errors are not associated
> to an specific dimm, but, instead, are related to a problem at the memory
> bus.
>=20
> Also, depending on how the memory controllers are organized[1], the ECC
> logic groups memory on DIMM pairs. So, when an error occur, it may be
> either at DIMM1 or DIMM2.
>=20
> [1] On Intel, this happens with pre-Nehalem memory controllers.
>=20
> Due to that, storing errors at the dimm struct sounds wrong, as the
> error may affect multiple DIMMs or even the entire layer.

That was my first thought too, but the counter values are not used at
all. The only exception is to provide *per-dimm* counters here:

 {ce,ue}_per_layer[n_layers-1][dimm->idx].=20

 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dr=
ivers/edac/edac_mc_sysfs.c?id=3D4f5cafb5cb8471e54afdc9054d973535614f7675#n5=
67
 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dr=
ivers/edac/edac_mc_sysfs.c?id=3D4f5cafb5cb8471e54afdc9054d973535614f7675#n5=
84

The case you mentioned above is if the mc only sends parts of the
error location (with a top, mid or low layer missing). The dimm cannot
be identified then. In this case edac_mc_handle_error() tries to find
a unique row (+ channel infomation if available and lists all possible
dimm labels in e->label. See:

 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dr=
ivers/edac/edac_mc.c?id=3D4f5cafb5cb8471e54afdc9054d973535614f7675#n1153

Thus, we see a counter increment for row (and also channel if it can
be identified), but this is counted in mci->csrows array only that is
not removed by this patch.

That said, the {ue,ce}_per_layer[] arrays can be removed by keeping
the same driver functionality, esp. the case you mentioned above.

-Robert