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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 67F69E77197 for ; Thu, 9 Jan 2025 14:24:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C45AA6B007B; Thu, 9 Jan 2025 09:24:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BF5E26B0082; Thu, 9 Jan 2025 09:24:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A9C6E6B0083; Thu, 9 Jan 2025 09:24:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 88E006B007B for ; Thu, 9 Jan 2025 09:24:41 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 3065C121915 for ; Thu, 9 Jan 2025 14:24:41 +0000 (UTC) X-FDA: 82988134362.04.65E9350 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf11.hostedemail.com (Postfix) with ESMTP id EC03740013 for ; Thu, 9 Jan 2025 14:24:38 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf11.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736432679; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FgjVDaKH89WSGXx4uio5gCncacTR4HqubCLZqwOAyXQ=; b=6LHDDTw1MMPTGPOS5jPRUvQs4SuMYAJHYthOi0dj2/dlSOKd6GiZ0vWqqBkWl6v/AZ+w8X KzQOGlXfQ/IdszRh6TLItSdi2x2ko0S05n+OPCznjF7Z/TgMtzoHlOnD4HDjtWchmReaKD iI+JqecJgZRPzAJ8of+7BlsSWVL5wxs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736432679; a=rsa-sha256; cv=none; b=Yba34XoO+/ROISFyzP81KSdpeA2A9GGEAHDQAu8bkpmHWPGhp4oS4hpBnxi8aOPZzFJQj3 0Rz2oNRF70uW+z4rLJv3Atbes7A0tTbUfeKxTrda3iJG7sE1sEGADsUzHJcykoab96u+/G w6Akz32KcATpLvqyl8tQb3cBbFaIcc4= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf11.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4YTRpD0FQlz6GFBq; Thu, 9 Jan 2025 22:23:00 +0800 (CST) Received: from frapeml500008.china.huawei.com (unknown [7.182.85.71]) by mail.maildlp.com (Postfix) with ESMTPS id 5C8DC140A34; Thu, 9 Jan 2025 22:24:36 +0800 (CST) Received: from localhost (10.203.177.66) by frapeml500008.china.huawei.com (7.182.85.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Thu, 9 Jan 2025 15:24:34 +0100 Date: Thu, 9 Jan 2025 14:24:33 +0000 From: Jonathan Cameron To: Borislav Petkov CC: Shiju Jose , "linux-edac@vger.kernel.org" , "linux-cxl@vger.kernel.org" , "linux-acpi@vger.kernel.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "tony.luck@intel.com" , "rafael@kernel.org" , "lenb@kernel.org" , "mchehab@kernel.org" , "dan.j.williams@intel.com" , "dave@stgolabs.net" , "dave.jiang@intel.com" , "alison.schofield@intel.com" , "vishal.l.verma@intel.com" , "ira.weiny@intel.com" , "david@redhat.com" , "Vilas.Sridharan@amd.com" , "leo.duran@amd.com" , "Yazen.Ghannam@amd.com" , "rientjes@google.com" , "jiaqiyan@google.com" , "Jon.Grimm@amd.com" , "dave.hansen@linux.intel.com" , "naoya.horiguchi@nec.com" , "james.morse@arm.com" , "jthoughton@google.com" , "somasundaram.a@hpe.com" , "erdemaktas@google.com" , "pgonda@google.com" , "duenwen@google.com" , "gthelen@google.com" , "wschwartz@amperecomputing.com" , "dferguson@amperecomputing.com" , "wbs@os.amperecomputing.com" , "nifan.cxl@gmail.com" , tanxiaofei , "Zengtao (B)" , "Roberto Sassu" , "kangkang.shen@futurewei.com" , wanghuiqiang , Linuxarm Subject: Re: [PATCH v18 04/19] EDAC: Add memory repair control feature Message-ID: <20250109142433.00004ea7@huawei.com> In-Reply-To: <20250109123222.GBZ3_B1g3Esgu1-MPi@fat_crate.local> References: <20250106121017.1620-1-shiju.jose@huawei.com> <20250106121017.1620-5-shiju.jose@huawei.com> <20250109091915.GAZ3-Uk3rkuh38cQyy@fat_crate.local> <3b2d4275d1d24dbeacee0f192ac4d69b@huawei.com> <20250109123222.GBZ3_B1g3Esgu1-MPi@fat_crate.local> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.42; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.203.177.66] X-ClientProxiedBy: lhrpeml100003.china.huawei.com (7.191.160.210) To frapeml500008.china.huawei.com (7.182.85.71) X-Rspamd-Queue-Id: EC03740013 X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: mxan3hgcx93u9gfc3xaifwwsn7wbihix X-HE-Tag: 1736432678-72340 X-HE-Meta: U2FsdGVkX18pASDSA+NAHCSzY8wYAwM3UmqfYl/R9LPwI56/pv6+b7Lj9nWJmBlsEnYKkh3rcYH3JuL+Objv9lLoQ29iBMg5FFN4Sl7BVoozrjuobrTOuGgwp5/T9QM1fLvRJpO1LtaDXFMgzjPhRA25C6Gl4xrA15I64mVQe8KkdjjOTbe1nFS9kJNNTIClpwbyhgJAQWnj3he158/X5teKKxPrOBEmhQVXy0N17TRgWzZ3iWRD4Ro5W4jYk+cl83WstSvdZaD4WnyAm+ZKh2da166gzwd+qUpdOTqgzlQNMq7C/xUHRmtYvhP1DuN7a63gy8lpH9wn51+aRy2XUEQCdrVJwcmCU3suL979STVTHvaBerjlSdd7VLkEyeRbv4sSukW8NiGxSK0kfDPQ9FrlzAJ0LPnQEc7Y8OvR9vDL3nHazJAQiQ/edF2RwHSwgh3+gG1z9YPvFSKa3ZOzwctwXj801DdPwQJgoj33ll+vWsTUTO1GBdUo/60EWxMggd9zeVeX5qpDG02eTNgWwKk3heajUacHDbgXEr40x2UMktvVvIlEjE7WoCQSBrrd0rH9DejTu6IuXckfAuw5Il1umnMWBje7VrN865kH0NTYFCbEb3EO1pxjaL3FT11CkmwXKfZh139dErpkKCf93AanzzJG6tCKpDbW/RDMWRJoCNzHhTVcICckTxaEg6yrUnLq3fmhfgniGJrtObR8PGYpbhEwjQIG1SACcyBS65c8hac5NO5qeJFeyV7xf4FakMEl9fi5f0ohACCjhAMJjDcDrJHwM2JAXUvB+1efItcYyUSDrGa+5oxZsE6QbU6U2xCVZkIVnOSNeEEnAKcsFqekzzvnmwOhPtu6XrG6o8iTtxWh+W+uq/xMY/qLwW2+Ygp/URgBAW20vUfbc1re4fUnS2HK+4nOHDCTVPObezJaW0jAtspa+OcD+rA3spcqqWUgG9ak0/sRqQ+FEQy EHBUAqwZ wmUYdZjHQwtj+KvtLxMJ+XgPJtav/P5fNG40RUgl2o4Ub4pfLCxv7BXeGqQH5PEehQ8y4c8uiwZpP7yHJf6oAXW6MJe3TQpyX3I7vNPrM2b6qNQUKS/9qz+KzmFaQJhtkgN905almbEitXvAppNUgTFRGw5aYneD5DU+XN0UZmiOqqqOML1+5il6La4npNnjSjQyhxNsNiHArOxUi2D+CDs3WN+CS5TNwYzlvT2HpMK344mj4vgxgw9TCow== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, 9 Jan 2025 13:32:22 +0100 Borislav Petkov wrote: Hi Boris, > On Thu, Jan 09, 2025 at 11:00:43AM +0000, Shiju Jose wrote: > > The min_ and max_ attributes of the control attributes are added for your > > feedback on V15 to expose supported ranges of these control attributes to the user, > > in the following links. > > Sure, but you can make that differently: > > cat /sys/bus/edac/devices//mem_repairX/bank > [x:y] > > which is the allowed range. To my thinking that would fail the test of being an intuitive interface. To issue a repair command requires that multiple attributes be configured before triggering the actual repair. Think of it as setting the coordinates of the repair in a high dimensional space. In the extreme case of fine grained repair (Cacheline), to identify the relevant subunit of memory (obtained from the error record that we are basing the decision to repair on) we need to specify all of: Channel, sub-channel, rank, bank group, row, column and nibble mask. For coarser granularity repair only specify a subset of these applies and only the relevant controls are exposed to userspace. They are broken out as specific attributes to enable each to be set before triggering the action with a write to the repair attribute. There are several possible alternatives: Option 1 "A:B:C:D:E:F:G:H:I:J" opaque single write to trigger the repair where each number is providing one of those coordinates and where a readback let's us known what each number is. That single attribute interface is very hard to extend in an intuitive way. History tell us more levels will be introduced in the middle, not just at the finest granularity, making such an interface hard to extend in a backwards compatible way. Another alternative of a key value list would make for a nasty sysfs interface. Option 2 There are sysfs interfaces that use a selection type presentation. Write: "C", Read: "A, B, [C], D" but that only works well for discrete sets of options and is a pain to parse if read back is necessary. So in conclusion, I think the proposed multiple sysfs attribute style with them reading back the most recent value written is the least bad solution to a complex control interface. > > echo ... > > then writes in the bank. > > > ... so we would propose we do not add max_ and min_ for now and see how the > > use cases evolve. > > Yes, you should apply that same methodology to the rest of the new features > you're adding: only add functionality for the stuff that is actually being > used now. You can always extend it later. > > Changing an already user-visible API is a whole different story and a lot lot > harder, even impossible. > > So I'd suggest you prune the EDAC patches from all the hypothetical usage and > then send only what remains so that I can try to queue them. Sure. In this case the addition of min/max was perhaps a wrong response to your request for a way to those ranges rather than just rejecting a write of something out of range as earlier version did. We can revisit in future if range discovery becomes necessary. Personally I don't think it is given we are only taking these actions in response error records that give us precisely what to write and hence are always in range. Jonathan > > Thx. >