From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Subject: Raise maximum number of memory controllers From: Mauro Carvalho Chehab Message-Id: <20180927221054.580220e5@coco.lan> Date: Thu, 27 Sep 2018 22:10:54 -0300 To: Borislav Petkov Cc: "Luck, Tony" , Russ Anderson , Greg KH , Justin Ernst , russ.anderson@hpe.com, Mauro Carvalho Chehab , linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org, Aristeu Rozanski Filho List-ID: RW0gRnJpLCAyOCBTZXAgMjAxOCAwMDowMzo1NSArMDIwMApCb3Jpc2xhdiBQZXRrb3YgPGJwQGFs aWVuOC5kZT4gZXNjcmV2ZXU6Cgo+IE9uIFRodSwgU2VwIDI3LCAyMDE4IGF0IDAyOjQ0OjAxUE0g LTA3MDAsIEx1Y2ssIFRvbnkgd3JvdGU6Cj4gPiBUaGUgcHJvYmxlbSB3aXRoIHlvdXIgcGF0Y2gg dGhhdCBnZXRzIHJpZCBvZiBFREFDX01BWF9NQ1MgaXMgbWFraW5nCj4gPiBkZXZpY2UgbGlua3Mg dW5kZXIgL3N5cy9idXMvZWRhYy4gIFdoaWNoIGlzIGhpbnRlZCBhdCBpbiBzb21lIG9mIHRoZQo+ ID4gY29kZSB5b3VyIHBhdGNoIGRlbGV0ZWQ6Cj4gPiAKPiA+IC0gICAgICAgLyoKPiA+IC0gICAg ICAgICogVGhlIG1lbW9yeSBjb250cm9sbGVyIG5lZWRzIGl0cyBvd24gYnVzLCBpbiBvcmRlciB0 byBhdm9pZAo+ID4gLSAgICAgICAgKiBuYW1lc3BhY2UgY29uZmxpY3RzIGF0IC9zeXMvYnVzL2Vk YWMuCj4gPiAtICAgICAgICAqLwo+ID4gLSAgICAgICBuYW1lID0ga2FzcHJpbnRmKEdGUF9LRVJO RUwsICJtYyVkIiwgbWNpLT5tY19pZHgpOwo+ID4gLSAgICAgICBpZiAoIW5hbWUpCj4gPiAtICAg ICAgICAgICAgICAgcmV0dXJuIC1FTk9NRU07Cj4gPiAtCj4gPiAtICAgICAgIG1jaS0+YnVzLT5u YW1lID0gbmFtZTsgIAo+IAo+IFllcywgYW5kIHRoYXQgbmVlZGVkIHRvIGdvIGJlY2F1c2UgSSBh bSB1c2luZyBhIHNpbmdsZSBidXMuIFdoaWNoIGtpbmRhCj4gbWFrZXMgc2Vuc2UgYmVjYXVzZSB5 b3Ugd2FudCB0byBoYXZlIGEgc2luZ2xlIGJ1cyBhbmQgbXVsdGlwbGUgZGV2aWNlcwo+IG9uIGl0 LiBJIG1lYW4sIGlmIHdlICpoYXZlKiB0byBoYXZlIGEgYnVzLgo+IAo+IEkgdGhpbmsgdGhpcyB3 aG9sZSAvc3lzL2J1cy9lZGFjIHRoaW5nIGlzIGNyYXAgYW5kIG5lZWRzIHRvIGdvLiBXZQo+IGhh dmUgYSBwZXJmZWN0bHkgZmluZSBoaWVyYXJjaHkgdW5kZXIgL3N5cy9kZXZpY2VzL3N5c3RlbS9l ZGFjIGFuZAo+IGR1cGxpY2F0aW5nIGl0IHVuZGVyIC9zeXMvYnVzL2VkYWMgaXMganVzdCBib2xs b2Nrcy4gSU1ITy4gRmVlbCBmcmVlIHRvCj4gY29ycmVjdCBtZSB3aXRoLCBidXQgYnV0LCB0aGlz IGlzIHVzZWZ1bCBmb3IuLi4KPiAKPiA+IHdoaWNoIHNlZW1lZCB0byB3b3JrLiAgCj4gCj4gUmln aHQuCj4gCj4gPiBCdXQgdGhlbiBJIGJlZ2FuIHdvbmRlcmluZyB3aGF0IGFyZSBBQkkgZXhwZWN0 YXRpb25zCj4gPiBmcm9tIGFwcGxpY2F0aW9ucyB0aGF0IHJlYWQgdGhlIEVEQUMgL3N5cyBmaWxl cz8KPiA+IAo+ID4gSXMgdGhpcyB0aGlzIGN1cnJlbnQgc291cmNlIHJlcG9zaXRvcnk/ICBodHRw czovL2dpdGh1Yi5jb20vZ3JvbmRvL2VkYWMtdXRpbHMKPiA+IAo+ID4gVGhpcyBjb2RlIGRvZXNu J3Qgc2VlbSB0byBrbm93IGFib3V0IHRoZSAiZGltbSoiIGRpcmVjdG9yaWVzIGJlbG93IHRoZQo+ ID4gIm1jKiIgbGV2ZWwuIEl0IGp1c3QgbG9va3MgZm9yIHRoZSBjc3JvdyogZW50cmllcy4gIAo+ IAo+IEkgZ3Vlc3MgdGhpcyBpcyBhIHF1ZXN0aW9uIGZvciBNYXVyby4gSSBuZXZlciByZWFsbHkg bmVlZGVkIGFueSBzcGVjaWFsCj4gZWRhYyB0b29sIHRvIGdldCBpbmZvIGFuZCBpZiB5b3UgYXNr IG1lLCB3ZSBwcm9iYWJseSBzaG91bGQgdHJ5IHRvIGtlZXAKPiBpdCBzaW1wbGUgYW5kIGdyZXAg c3lzZnMuIFNvIHRoYXQgeW91IGNhbiBhbHdheXMgZ2V0IHRoZSBpbmZvIHdpdGhvdXQKPiBoYXZp bmcgdG8gaW5zdGFsbCBhbnkgc3BlY2lhbCB0b29scy4gTGlrZSBmdHJhY2Ugd29ya3Mgb24gZXZl cnkgc3lzdGVtCj4gd2l0aCBqdXN0IGEgc2hlbGwgYW5kIGJhc2ljIHRvb2xzLiBJIHRoaW5rIHRo aXMgaXMgdmVyeSBwb3dlcmZ1bC4gQnV0Cj4gdGhpcyBpcyBvbGQgc3BhcnRhbiBtZSBvbmx5IHRo aW5raW5nIG91dCBsb3VkLgo+IAo+IEluIGFueSBjYXNlLCBJJ20gbW9yZSB0aGFuIGZpbmUgd2l0 aCBkcm9wcGluZyB0aGUgYnVzIGhpZXJhcmNoeSBpZgo+IG5vdGhpbmcgdXNlcyBpdC4KCkkgZG9u J3QgcmVtZW1iZXIgYWJvdXQgYW55IHJhdGlvbmFsZSBiZWhpbmQgL3N5cy9idXMvZWRhYy4gSXQg d2FzCnRoZXJlIGFscmVhZHkgYmVmb3JlIEkgc3RhcnQgd29ya2luZyBvbiBFREFDIGFib3V0IDEw IHllYXJzIGFnby4KSSBndWVzcyBpdCB3YXMgdXNlZCBpbiB0aGUgcGFzdCBieSBlZGFjLXV0aWxz IChvciBtYXliZSBpdCBpcyBqdXN0IGEKc2lkZSBlZmZlY3Qgb2YgdGhlIG5lZWQgdG8gY3JlYXRl IGEgYnVzIG9uIHNvbWUgcGFzdCkuCgpCdHcsIFRoZSBkb2N1bWVudGVkIEVEQUMgQUJJIGlzIC9z eXMvZGV2aWNlcy9zeXN0ZW0vZWRhYywgYXMKZGVzY3JpYmVkIGF0IERvY3VtZW50YXRpb24vQUJJ L3Rlc3Rpbmcvc3lzZnMtZGV2aWNlcy1lZGFjLgoKU28sIEkgc3VzcGVjdCBpdCBzaG91bGQgYmUg c2FmZSB0byBnZXQgcmlkIG9mIC9zeXMvYnVzL2VkYWMsCnByb3ZpZGVkIHRoYXQgaXQgd29uJ3Qg Y2F1c2Ugc2lkZSBlZmZlY3RzIGF0IC9zeXMvZGV2aWNlcy9zeXN0ZW0vZWRhYy4KCldoeSBJIHRo aW5rIGl0IGlzIHNhZmUgdG8gZ2V0IHJpZCBvZiAvc3lzL2J1cy9lZGFjPwotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCkFzIGZhciBhcyBJIGNhbiB0 ZWxsLCB0aGVyZSBhcmUgb25seSB0d28gdG9vbHNldHM6IHRoZSBsZWdhY3kgZWRhYy11dGlscwph bmQgdGhlIHJhc2RhZW1vbi4gQXQgbGVhc3Qgb24gRmVkb3JhIDI4LCBib3RoIGFwcGxpY2F0aW9u cyBhcmUgCnBhY2thZ2VkIChtZWFuaW5nIHRoYXQgdGhlcmUgYXJlIHByb2JhYmx5IHBlb3BsZSB1 c2luZyBib3RoKS4KClRoZSBlZGFjLXV0aWxzIHVzZXMgdGhlIG9sZCBzeXNmcyBlbnRyaWVzICh0 aGUgb25lcyB3aG9zZSBlbnRyaWVzCmFyZSBkYXRlZCB1cCB0byAyMDA3KS4gSSBkb24ndCBzZWUg YW55IGNoYW5nZXMgdXBzdHJlYW0gZm9yIGl0CnNpbmNlIDIwMDg6CgoJaHR0cHM6Ly9zb3VyY2Vm b3JnZS5uZXQvcHJvamVjdHMvZWRhYy11dGlscy8KCkkgZGlkIGEgZ3JlcCBvbiBpdHMgc291cmNl IGNvZGUgKG9uIGl0cyB2ZXJzaW9uIDAuMTYsIGZyb20gMjAxOCkuIEl0IHNlZW1zCnRoYXQgaXQg dXNlcyBvbmx5IC9zeXMvZGV2aWNlcy9zeXN0ZW0vZWRhYy4KClRoZSByYXNkYWVtb24gdXNlcyBh bHNvIHRoZSBuZXcgc3lzZnMgZW50cmllcyAodGhlIG9uZXMgZGF0ZWQgYXMKMjAxMiBhbmQgMjAx NikuIEknbSBtYWludGFpbmluZyBpdC4gUmFzdG9vbCBub3Qgb25seSByZWNlaXZlIHRyYWNlcywK YnV0IGl0IGNhbiBhbHNvIHN0b3JlIHRoZW0gb24gYSBkYXRhYmFzZSBhbmQgZXZlbiBnZW5lcmF0 ZSBBQlJUIGV2ZW50cy4KSXQgYWxzbyB1c2VzIG9ubHkgL3N5cy9kZXZpY2VzL3N5c3RlbS9lZGFj LgoKT24gYm90aCB0b29sc2V0cywgdGhlIHN5c2ZzIGVudHJpZXMgdGhlcmUgYXJlIGltcG9ydGFu dCwgaW4gb3JkZXIgdG8gCm5vdCBvbmx5IGxpc3QgdGhlIG1lbW9yeSBsYXlvdXQgYW5kIGVycm9y IGNvdW50cywgYnV0IGFsc28gdG8gc3RvcmUKdGhlIGRpbW0gbGFiZWxzLgoKVGhlIHJhc2RhZW1v biBpdHNlbGYgdXNlcyBwZXJmIHRyYWNlIGV2ZW50cywgYWx0aG91Z2ggQXJpcyBhZGRlZApzdXBw b3J0IGZvciBpdCB0byB3b3JrIG9uIG5vbi1kYWVtb24gbW9kZSwgd2hlcmUgaXQganVzdCByZWFk cwp0aGUgY291bnRlcnMgdmlhIHN5c2ZzLCBhdCAvc3lzL2RldmljZXMvc3lzdGVtL2VkYWMuCgpU aGFua3MsCk1hdXJvCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1658AC43382 for ; Fri, 28 Sep 2018 01:11:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CABE821733 for ; Fri, 28 Sep 2018 01:11:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="otL/vCqL" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CABE821733 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728686AbeI1Hch (ORCPT ); Fri, 28 Sep 2018 03:32:37 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:50658 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728582AbeI1Hcg (ORCPT ); Fri, 28 Sep 2018 03:32:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To: From:Date:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=RQTIFlhiAbF14gcWHKH9T8TTV28V1GiSODEwWQGimms=; b=otL/vCqLRigPh+AGVOkK3ZVIA JVFuAGQ0IiZsCe/rKr6Zs/GdoDPOSrat8LW4LTuhDDsFiscHsnF3uTmU6o/6gqvHtj++eefCl2pdb AAyod6bmlnMi4vWhfjB1XRQGc/8HtvH9ch5NgsjPBIoSw4qkmFsOp8sZdnVyeEu1tW887UuOOb+Pz lkuRGCVRJX6/rcllUViHF4KZX85zApHaLr6nkUr4x5+c0NAGpgwHhRj/cH6X8AuHJFVo+qRC4xAGv fr/TB4HHyYlyQI5LVa14p8D9Ex09Y7QrAKehmQVmL/38nX0Hpo/5NWHq6mD5VCvEyDRsjyjfgOEB9 EHgm/5Kbg==; Received: from 177.41.129.251.dynamic.adsl.gvt.net.br ([177.41.129.251] helo=coco.lan) by bombadil.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1g5hJ7-0003t2-K0; Fri, 28 Sep 2018 01:11:23 +0000 Date: Thu, 27 Sep 2018 22:10:54 -0300 From: Mauro Carvalho Chehab To: Borislav Petkov Cc: "Luck, Tony" , Russ Anderson , Greg KH , Justin Ernst , russ.anderson@hpe.com, Mauro Carvalho Chehab , linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org, Aristeu Rozanski Filho Subject: Re: [PATCH] Raise maximum number of memory controllers Message-ID: <20180927221054.580220e5@coco.lan> In-Reply-To: <20180927220355.GF19687@zn.tnic> References: <20180925180458.GG23986@zn.tnic> <20180926093510.GA5584@zn.tnic> <20180926152752.GG5584@zn.tnic> <20180926130340.6b22918b@coco.lan> <20180926161749.GI5584@zn.tnic> <20180926181035.GA1132@agluck-desk> <20180926182317.patqjso7nzw2oxiz@hpe.com> <20180926230257.GA5666@agluck-desk> <20180927045244.GA30912@zn.tnic> <20180927214400.GA2249@agluck-desk> <20180927220355.GF19687@zn.tnic> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Fri, 28 Sep 2018 00:03:55 +0200 Borislav Petkov escreveu: > On Thu, Sep 27, 2018 at 02:44:01PM -0700, Luck, Tony wrote: > > The problem with your patch that gets rid of EDAC_MAX_MCS is making > > device links under /sys/bus/edac. Which is hinted at in some of the > > code your patch deleted: > > > > - /* > > - * The memory controller needs its own bus, in order to avoid > > - * namespace conflicts at /sys/bus/edac. > > - */ > > - name = kasprintf(GFP_KERNEL, "mc%d", mci->mc_idx); > > - if (!name) > > - return -ENOMEM; > > - > > - mci->bus->name = name; > > Yes, and that needed to go because I am using a single bus. Which kinda > makes sense because you want to have a single bus and multiple devices > on it. I mean, if we *have* to have a bus. > > I think this whole /sys/bus/edac thing is crap and needs to go. We > have a perfectly fine hierarchy under /sys/devices/system/edac and > duplicating it under /sys/bus/edac is just bollocks. IMHO. Feel free to > correct me with, but but, this is useful for... > > > which seemed to work. > > Right. > > > But then I began wondering what are ABI expectations > > from applications that read the EDAC /sys files? > > > > Is this this current source repository? https://github.com/grondo/edac-utils > > > > This code doesn't seem to know about the "dimm*" directories below the > > "mc*" level. It just looks for the csrow* entries. > > I guess this is a question for Mauro. I never really needed any special > edac tool to get info and if you ask me, we probably should try to keep > it simple and grep sysfs. So that you can always get the info without > having to install any special tools. Like ftrace works on every system > with just a shell and basic tools. I think this is very powerful. But > this is old spartan me only thinking out loud. > > In any case, I'm more than fine with dropping the bus hierarchy if > nothing uses it. I don't remember about any rationale behind /sys/bus/edac. It was there already before I start working on EDAC about 10 years ago. I guess it was used in the past by edac-utils (or maybe it is just a side effect of the need to create a bus on some past). Btw, The documented EDAC ABI is /sys/devices/system/edac, as described at Documentation/ABI/testing/sysfs-devices-edac. So, I suspect it should be safe to get rid of /sys/bus/edac, provided that it won't cause side effects at /sys/devices/system/edac. Why I think it is safe to get rid of /sys/bus/edac? --------------------------------------------------- As far as I can tell, there are only two toolsets: the legacy edac-utils and the rasdaemon. At least on Fedora 28, both applications are packaged (meaning that there are probably people using both). The edac-utils uses the old sysfs entries (the ones whose entries are dated up to 2007). I don't see any changes upstream for it since 2008: https://sourceforge.net/projects/edac-utils/ I did a grep on its source code (on its version 0.16, from 2018). It seems that it uses only /sys/devices/system/edac. The rasdaemon uses also the new sysfs entries (the ones dated as 2012 and 2016). I'm maintaining it. Rastool not only receive traces, but it can also store them on a database and even generate ABRT events. It also uses only /sys/devices/system/edac. On both toolsets, the sysfs entries there are important, in order to not only list the memory layout and error counts, but also to store the dimm labels. The rasdaemon itself uses perf trace events, although Aris added support for it to work on non-daemon mode, where it just reads the counters via sysfs, at /sys/devices/system/edac. Thanks, Mauro