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 6BA9FC25B10 for ; Fri, 10 May 2024 13:31:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 912DC6B00E0; Fri, 10 May 2024 09:31:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 89BBA6B00E1; Fri, 10 May 2024 09:31:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 763856B00E2; Fri, 10 May 2024 09:31:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 57C226B00E0 for ; Fri, 10 May 2024 09:31:52 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id C678916011A for ; Fri, 10 May 2024 13:31:51 +0000 (UTC) X-FDA: 82102574022.22.FCBBB91 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf23.hostedemail.com (Postfix) with ESMTP id C59D0140022 for ; Fri, 10 May 2024 13:31:48 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf23.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=1715347909; 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=63o0IyEk86A4uVJMfFL7wmhWdO6N6EMqW+NXmSXdtBk=; b=fmE+LOKKXBx6txdI0M016a+FybDfR1+gd5JUZO2dS0ws7dqAmKYquoDgDZeLT15rjMGWb2 EXh2Bei8kVlewa2Fur01tb9kqMszJMBYc0b4WJvO2q6ULYg0OTuJ86KZC6+BQV9B7xXuGz hVkdSAlEf7yfUprRkxodx32x0rmMYgU= 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 jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715347909; a=rsa-sha256; cv=none; b=nwtaIM0vsIBkDpeluqcaxzu7am0bDuJn+kg0g3vgE8e+ibrv6m56KlFwnSimmpky3K+D/E f1emYlXCGXVQehcAz3UqkTB4SZ42chDkIcU8BjHhFSpVl7SRyfDWFA+bZB/a/BzU3offKY vi0nFTbEuwQwOecdX85PwJkIefVvkDk= Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4VbV7z4xFKz6K5ks; Fri, 10 May 2024 21:28:31 +0800 (CST) Received: from lhrpeml500005.china.huawei.com (unknown [7.191.163.240]) by mail.maildlp.com (Postfix) with ESMTPS id C21D61400D4; Fri, 10 May 2024 21:31:43 +0800 (CST) Received: from localhost (10.202.227.76) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Fri, 10 May 2024 14:31:42 +0100 Date: Fri, 10 May 2024 14:31:41 +0100 From: Jonathan Cameron To: Borislav Petkov CC: Shiju Jose , "linux-cxl@vger.kernel.org" , "linux-acpi@vger.kernel.org" , "linux-mm@kvack.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" , "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" , "wbs@os.amperecomputing.com" , "nifan.cxl@gmail.com" , tanxiaofei , "Zengtao (B)" , "kangkang.shen@futurewei.com" , wanghuiqiang , Linuxarm , "Greg Kroah-Hartman" , Jean Delvare , Guenter Roeck , Dmitry Torokhov Subject: Re: [RFC PATCH v8 01/10] ras: scrub: Add scrub subsystem Message-ID: <20240510143141.000042da@Huawei.com> In-Reply-To: References: <20240419164720.1765-1-shiju.jose@huawei.com> <20240419164720.1765-2-shiju.jose@huawei.com> <20240425101542.GAZiotThrq7bOE9Ieb@fat_crate.local> <63fdbe26b51f4b7c859bfb30287c8673@huawei.com> <20240506103014.GHZjixNhhFkgkMhDg_@fat_crate.local> <20240508172002.GGZju0QvNfjB7Xm6qL@fat_crate.local> <4ceb38897d854cc095fca1220d49a4d2@huawei.com> <20240508192546.GHZjvRuvtu0XSJbkmz@fat_crate.local> <20240509101939.0000263a@Huawei.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.202.227.76] X-ClientProxiedBy: lhrpeml500005.china.huawei.com (7.191.163.240) To lhrpeml500005.china.huawei.com (7.191.163.240) X-Stat-Signature: 7pxrxtg7da1y6or7xuma4dnzy6wdh1w8 X-Rspamd-Queue-Id: C59D0140022 X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1715347908-679961 X-HE-Meta: U2FsdGVkX18DZFOKBnOHSI06ICINfRE6jTe1EIY5T9vi7FSDlAekMItW2pPUp/nV3g34HD2B/36cl7mF3Dmlf0aGl9lE9p8wBmWnhODB3fS5oVWS3hpLBGrAdkQNT8BxD2V6+A1bCRIxCPzH3Z1mZGN4tltIgPiH+kDCkvfEMi4ATDLHceGizGCytOEPDn10dVbPUcayGvsMRmuzEdJVXvHZpUAFS6E+GSDFcPayJp0u8SV0Swv0c+U1HrqNGK14PIF+Mt/OWrcb8omNqY5xNQVsi1wnfd/Kk20M0VGdYXZihD/DJ6FluSSeUKMjpK3w4X6YWldnYTSVimtcyBO1YlwxCzubhUfnRa2rfiBwL7CSXOyNPScx+HhTnEeuxfV09cBlgkqFPYfaf4QdLZcxbVfD8Er1xCXzHDAZrkJrc38641e5BD7cJ92bpZ5H52fHEA9hFzli/ATko4SyXYew19UXO3jKOeYdvgA0JJf2yAMkHTuIFXa4GJS8ISkUAGUgsKboBAvid6eMXl3MoVgLnMAoFhp/YwOl2tfsuILOXV41sEckCAkZV+dFO4pejWtJfaCQpt6s416sDm4kNZ17ZuQEQDuAC0bP5RQXxzt9qDoxBFICnlGkq7DqvyZdHotJEIopM1z8VrJ7GvwRBR4wSuoZu97elgDpaJJoaCv9OLhWKRzzXtp0NYsSiGIh/Va2PQHm1penAu2TdraJ3XUWhuGwzRrTh1SE4mcVAzfMCcjmD+ddcwLQUlal8gihoqblKXLbReBeoYTX47gVIZ6ZBqET+KviAWtcVpKlxyNkP+o2bOAohVtCGJnLIzYZ3cpa33U0lsxzifYhIt6Ttq1CHMnRvE2RkRowajYqF53DevtiURg3QtGUj0O8JHQsTkslOlPfjFURlevbmK7i/YrkU2cLA+XvAxxLpp3XI7c+xcpP7cmEtLMW3h0nrOklzD5hrR2/AXGamlCksNzommt LMWMbfbS Dp0ZT2R+67sIv+IC6UqJxvnlmDLoC+za+Y1BgtZ8aXbTK1SLpRSF0QUQPUOpgmnpDYyn63Mda9uOWLvs1hXlWekh4jCtCiHyHm+rppIGyY9ML8EqT9WxerjJ+VPxACeUuwIB1OUi2jRpKg6k8nlkdQiTHtOYSzWr/fGP3w2DgM8EMzm/x0gSSGEL+nMbAaRcsLmlW49NALDreOhfud6gZ3KgpJsfH0FHyWXKihLCXlF79ZFHZyQpd3R7ZFJQo5FtW6jw2SPvmNOEn8UCw9FNSmXQDaKlkYUcgbTHFV30kOslpqG9qOxRp7nWeKdGbdttqChQK X-Bogosity: Ham, tests=bogofilter, spamicity=0.000004, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: > How hard is that "jump through hoops" thing anyway? I'd conservatively estimate 500 lines of duplicated code from the CXL subsystem just to handle the setup and discovery of the mailbox, plus all the checks needed to establish the device is in a state to reply. Also locking or module load ordering constraints because we need to ensure mutual exclusion on that mailbox between this module and the CXL core. So it would approximately triple the size of this driver to check for CXL scrub support. Not to mention hotplug - which could possibly be solved with appropriate udev rules to try loading this again whenever a CXL memory device gets plugged in. Alternative would be to make this ras class driver dependent on the CXL driver stack running first. Thus if you wanted RAS2 ACPI table support, you'd need to load a whole bunch of CXL stuff. Add another similar driver in future and we get another few 100 lines of code or another dependency. To me those numbers make it unsustainable. > > You mean it should load so that when booting an allmodconfig kernel there are not enough modules which are loading so lemme load one more. And then I need to go and rmmod them all before I need to do localmodconfig and build a tailored kernel for the machine. > > Or is there some other reason to load silly modules, use up resources for no good reason whatsoever and bloat the machine? As Dan, Shiju and I observed (and Shiju tested to be sure we weren't getting it wrong), normal setups including your allmodconfig build would not even load the driver. What are we missing? Jonathan