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 2B27FC54798 for ; Fri, 23 Feb 2024 12:16:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9C66B6B006E; Fri, 23 Feb 2024 07:16:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 975F16B0071; Fri, 23 Feb 2024 07:16:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 817346B0072; Fri, 23 Feb 2024 07:16:30 -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 703A56B006E for ; Fri, 23 Feb 2024 07:16:30 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 0BE841A10BC for ; Fri, 23 Feb 2024 12:16:30 +0000 (UTC) X-FDA: 81822966540.19.027E6E6 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf23.hostedemail.com (Postfix) with ESMTP id B7FFE140009 for ; Fri, 23 Feb 2024 12:16:26 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf23.hostedemail.com: domain of shiju.jose@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=shiju.jose@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708690587; 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=NUMwffL+IUE123iK6fc0PXioWDWokI81fTrq0RBm+NE=; b=8SDsjZTLuWKOjVmzINtJ7xWv6yKywk+ns4inJzxAOMWA1z2dY0tVvr/zt56fXcm7UJLaia yZdISpbdl4hcPZLZJcS7x3T7IIvpbEp1OFBEJAWdNu8coWpsDcI/r/BQXtkuEEOA7iriSB lE9KhPIGfSS6tsGPAG5WNOvWc90ogow= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf23.hostedemail.com: domain of shiju.jose@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=shiju.jose@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708690587; a=rsa-sha256; cv=none; b=vNKHSXesveU+UhNU7WEeXI7dHzTEZRY/e+/VlS+/7DDolkdrIXzv4X3sMM064ZuoChcP3K K8XEzicTP10C//g/RUexdA5pFZgvEG0okuqfK3Dx84IKXXOlLAtIsL/Sim3NOWXWimFfds v/4Z9KJn+5B9MIxqf3VNF6QmxCfxbZI= Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Th8655Ks2z6K8Xc; Fri, 23 Feb 2024 20:12:45 +0800 (CST) Received: from lhrpeml100002.china.huawei.com (unknown [7.191.160.241]) by mail.maildlp.com (Postfix) with ESMTPS id 9E516140D1A; Fri, 23 Feb 2024 20:16:24 +0800 (CST) Received: from lhrpeml500006.china.huawei.com (7.191.161.198) by lhrpeml100002.china.huawei.com (7.191.160.241) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Fri, 23 Feb 2024 12:16:24 +0000 Received: from lhrpeml500006.china.huawei.com ([7.191.161.198]) by lhrpeml500006.china.huawei.com ([7.191.161.198]) with mapi id 15.01.2507.035; Fri, 23 Feb 2024 12:16:24 +0000 From: Shiju Jose To: Dan Williams , "linux-cxl@vger.kernel.org" , "linux-acpi@vger.kernel.org" , "linux-mm@kvack.org" , "dave@stgolabs.net" , Jonathan Cameron , "dave.jiang@intel.com" , "alison.schofield@intel.com" , "vishal.l.verma@intel.com" , "ira.weiny@intel.com" CC: "linux-edac@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "david@redhat.com" , "Vilas.Sridharan@amd.com" , "leo.duran@amd.com" , "Yazen.Ghannam@amd.com" , "rientjes@google.com" , "jiaqiyan@google.com" , "tony.luck@intel.com" , "Jon.Grimm@amd.com" , "dave.hansen@linux.intel.com" , "rafael@kernel.org" , "lenb@kernel.org" , "naoya.horiguchi@nec.com" , "james.morse@arm.com" , "jthoughton@google.com" , "somasundaram.a@hpe.com" , "erdemaktas@google.com" , "pgonda@google.com" , "duenwen@google.com" , "mike.malvestuto@intel.com" , "gthelen@google.com" , "wschwartz@amperecomputing.com" , "dferguson@amperecomputing.com" , tanxiaofei , "Zengtao (B)" , "kangkang.shen@futurewei.com" , wanghuiqiang , Linuxarm Subject: RE: [RFC PATCH v6 00/12] cxl: Add support for CXL feature commands, CXL device patrol scrub control and DDR5 ECS control features Thread-Topic: [RFC PATCH v6 00/12] cxl: Add support for CXL feature commands, CXL device patrol scrub control and DDR5 ECS control features Thread-Index: AQHaYAA5w4x9+ofZHUSoNACgT3S68LEVigKAgAJRu3A= Date: Fri, 23 Feb 2024 12:16:23 +0000 Message-ID: <54c55412e9374e4e9cacf8410a5a98cb@huawei.com> References: <20240215111455.1462-1-shiju.jose@huawei.com> <65d6936952764_1138c7294e@dwillia2-xfh.jf.intel.com.notmuch> In-Reply-To: <65d6936952764_1138c7294e@dwillia2-xfh.jf.intel.com.notmuch> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.48.145.174] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: B7FFE140009 X-Stat-Signature: 81ns4ets9deex6go3jriugxdh4r61yht X-HE-Tag: 1708690586-557672 X-HE-Meta: U2FsdGVkX18mOTC308KWS7iR1pAhvpzKUXt+dGvh/biQyH0HfsO7y/eVnH7+j1DACc5uTDIpAv/WbP71VfJ03AxRGvKZUKm88VNC0K3gFwiP28o0uajvNXh0TTPVryuIjLMxpCuDji+mVm6AlOcDlzCp2zeag8OPsv1R3XODtWNK6DdPqRr6zurMjbN9TPe6R57o4/8UutpmIMcy1WJR3odanQ0cn75Aa8SJkhmKOd1s39P2CYXc1jUTT7nHO6b9T9JxCiQ72IxgFzG+RXadFz4LnaIv7exJyOeNfLGr3ZoWXZuMPLnve4HPzE7YVq/lgHk3Lki3Ba4pn4T6gziImqS0R2Dgr8IYvjHpLheb5CsreqKsVAO40ygbgTzP17RT73YVBnO6FHbR0TU2Fx95derrigfSYP1PShpqmjLIAWx4hl2J/enF0zXb5c2FfjHTfBTKmnve6dgSoXFRHemUvQ6VODSgsSGWbtx88tY5g0hy427RljFeAfwm8EGwzp3cXAmXNsI19/YFSLvZRr2gmspZ8fLGVBG9Bb+nEHK93qEHbg+GsCSBaIp7KIZTLddgCySIlBv5+OXZ3FiN5xVKAHlT8mXfsMtaeI0TxC/nFYFDUQnGLWUr9QIFrSPjlp8P4Isw/GM5DARSBFN57oLVMZRkJHW811Ynwpqap9Ekcs5/STN5myA+W9CVV6O/p4ZIkIo8WrdcF8O+VvVPIBU62x00y9QaEF3kWct6n6WQllLq7nvVZPYTVxay4iC0xaKPz+ZqPe/6aQYf8Re9Z5ICkmiPQ+v+Hhq23Ysd/zlmkzvatTeGQJgWztzDvlbvHdKjd4DL2+1GJpGcYie6+opi+87ekzXohLGeC2Kolve/KdDUp3ChOMtoo/F4xwSwMmw6pAkgXajh8SYNkuCkumJR97hsNPljus5fBDcgNWWIhF4cT69WSkICfnuoWD2l5WXa9lI4z2Ne3EJS1eo/NV0 mL2o3EZv 4QURJqje/oZzkc6070ldhabDq4ynhwVNEPJC91PV9limLlvM1fk1XYUwV++sXQ5ybSKLiT1tQhH79FsAkfsL4sjE/VEzO/4ruAHZ0oqYqiC7DFf3qtEJXdrzzJOGz7PF3OF1TloNEsrzA87fNpHqywLUGT6qV8MOpXFdDL4LYAi5aqYHeIN3bVdjeQB5FA0ygab5cQnN6PozQ3nF9vUtRTijNUJWJE7siDbTODtNiZkaMlC7pxsRTya9b4RSfFC3SPETyP2X9j37hJsJx8cy8jj6MS2NEsr4+Y34KjYCK0SWKZ1FWcNUiDXciUcFnDlLLYcp98p82ibkyWcbdu1VjjEQUWbjrtBa1Rers523EkHW1grByHm68P1YUXZjgTwXjm4EyEvxdPl53MxxpHVnl7GDctYu9FMS7/tL+zGlAloAHzNIoMS/UnGzR4+TkEk4wy7nwmpyKxuAYYtAQOlj5XHiIIxkT7PgsO4olRsRvBNeBpaRJ6G01Qbyyy/1/pD+gMAMkPc+H3KHYnt+hK1O5AAuVpKTOUZ8LVszz2KJhGWr+6hqVe1ElXUfsZUsrCqf11QnJSQhO8e6bb/tCZ81K8W/UDoT5bSrmVakOE55gNsGhVl2qqWMukgH90BvRVq+PWzOwzSdXABBmiNv54LkOFFCKk4dpBwpURRk+nJ3wTXdsaYQVBS+ZmcF3h/Gd66UcW5G6B3JwYBVEAeo1sdAaohYhfvakuID0bsG7gCOSOTeJ9AMtIgNeg9MsDnxWEDsdSP7vbfXkUPrXdrvsWj6YduFoZMAflWajd8jpXGM+UKD6kXo= 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: Hi Dan, Thanks for the feedback. Please find reply inline. >-----Original Message----- >From: Dan Williams >Sent: 22 February 2024 00:21 >To: Shiju Jose ; linux-cxl@vger.kernel.org; linux- >acpi@vger.kernel.org; linux-mm@kvack.org; dan.j.williams@intel.com; >dave@stgolabs.net; Jonathan Cameron ; >dave.jiang@intel.com; alison.schofield@intel.com; vishal.l.verma@intel.com= ; >ira.weiny@intel.com >Cc: linux-edac@vger.kernel.org; linux-kernel@vger.kernel.org; >david@redhat.com; Vilas.Sridharan@amd.com; leo.duran@amd.com; >Yazen.Ghannam@amd.com; rientjes@google.com; jiaqiyan@google.com; >tony.luck@intel.com; Jon.Grimm@amd.com; dave.hansen@linux.intel.com; >rafael@kernel.org; lenb@kernel.org; naoya.horiguchi@nec.com; >james.morse@arm.com; jthoughton@google.com; somasundaram.a@hpe.com; >erdemaktas@google.com; pgonda@google.com; duenwen@google.com; >mike.malvestuto@intel.com; gthelen@google.com; >wschwartz@amperecomputing.com; dferguson@amperecomputing.com; >tanxiaofei ; Zengtao (B) = ; >kangkang.shen@futurewei.com; wanghuiqiang ; >Linuxarm ; Shiju Jose >Subject: RE: [RFC PATCH v6 00/12] cxl: Add support for CXL feature command= s, >CXL device patrol scrub control and DDR5 ECS control features > >shiju.jose@ wrote: >> From: Shiju Jose >> >> 1. Add support for CXL feature mailbox commands. >> 2. Add CXL device scrub driver supporting patrol scrub control and ECS >> control features. >> 3. Add scrub subsystem driver supports configuring memory scrubs in the >system. >> 4. Register CXL device patrol scrub and ECS with scrub subsystem. >> 5. Add common library for RASF and RAS2 PCC interfaces. >> 6. Add driver for ACPI RAS2 feature table (RAS2). >> 7. Add memory RAS2 driver and register with scrub subsystem. > >I stepped away from this patch set to focus on the changes that landed for= v6.8 >and the follow-on regression fixups. Now that v6.8 CXL work has quieted do= wn >and I circle back to this set for v6.9 I find the lack of story in this co= ver letter to >be unsettling. As a reviewer I should not have to put together the story o= n why >Linux should care about this feature and independently build up the >maintainence-burden vs benefit tradeoff analysis. I will add more details to the cover letter. =20 > >Maybe it is self evident to others, but for me there is little in these ch= angelogs >besides "mechanism exists, enable it". There are plenty of platform or dev= ice >mechanisms that get specified that Linux does not enable for one reason or >another. > >The cover letter needs to answer why it matters, and what are the tradeoff= s. >Mind you, in my submissions I do not always get this right in the cover le= tter [1], >but hopefully at least one of the patches tells the story [2]. > >In other words, imagine you are writing the pull request to Linus or someo= ne >else with limited time who needs to make a risk decision on a pull request= with a >diffstat of: > > 23 files changed, 3083 insertions(+) > >...where the easiest decision is to just decline. As is, these changelogs = are not >close to tipping the scale to "accept". > >[sidebar: how did this manage to implement a new subsystem with 2 consumer= s >(CXL + ACPI), without modifying a single existing line? Zero deletions? Th= at is >either an indication that Linux perfectly anticipated this future use case >(unlikely), or more work needs to be done to digest an integrate these con= cepts >into existing code paths] > >One of the first questions for me is why CXL and RAS2 as the first consume= rs and >not NVDIMM-ARS and/or RASF Patrol Scrub? Part of the maintenance burden We don't personally care about NVDIMMS but would welcome drivers from other= s. Regarding RASF patrol scrub no one cared about it as it's useless and any new implementation should be RAS2. Previous discussions in the community about RASF and scrub could be find he= re. https://lore.kernel.org/lkml/20230915172818.761-1-shiju.jose@huawei.com/#r and some old ones, https://patchwork.kernel.org/project/linux-arm-kernel/patch/CS1PR84MB003871= 8F49DBC0FF03919E1184390@CS1PR84MB0038.NAMPRD84.PROD.OUTLOOK.COM/ https://lore.kernel.org/all/20221103155029.2451105-1-jiaqiyan@google.com/ >tradeoff is providing a migration path for legacy on the way to adding the= new >thing. If old scrub implementations could be deprecated / deleted on the w= ay to >supporting new scrub use cases that becomes interesting. > >[1]: http://lore.kernel.org/r/20240208220909.GA975234@bhelgaas >[2]: http://lore.kernel.org/r/20240208221305.GA975512@bhelgaas Thanks, Shiju