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 A45C3E77188 for ; Tue, 14 Jan 2025 13:10:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 120836B007B; Tue, 14 Jan 2025 08:10:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A9746B0085; Tue, 14 Jan 2025 08:10:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E8B806B0088; Tue, 14 Jan 2025 08:10:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id CC9176B007B for ; Tue, 14 Jan 2025 08:10:36 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 56FD38091B for ; Tue, 14 Jan 2025 13:10:36 +0000 (UTC) X-FDA: 83006091672.20.AA47BAF Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf17.hostedemail.com (Postfix) with ESMTP id 7DAE94001E for ; Tue, 14 Jan 2025 13:10:34 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="l1nx/w9r"; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf17.hostedemail.com: domain of mchehab+huawei@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=mchehab+huawei@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736860234; a=rsa-sha256; cv=none; b=C3fQbwvGS0m9F/NXS3BhOgGiKyZ+DDJshVSZDv9Z6Q3vEh7upTu+f+3iRqJgM3W3ouxMLd t/7yXhwxkufwBmWS07SddaQjT+Rlvcf/ZcdHeq5FaD1jLDsN3zpbGL0l9qjzXJ0hrRicoT 932hLpXUffSJSqpliCZ03bG3nkclenA= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="l1nx/w9r"; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf17.hostedemail.com: domain of mchehab+huawei@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=mchehab+huawei@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736860234; 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:dkim-signature; bh=IZ4ILF6otARkv3+uyue6YslTqlnmPbbg8JtTyk0lddg=; b=uyoGhGX9ADXXelxRBhf16DWEBwB7a0iCmg4MHDqKwHBD1fmzeigoFMhtR1vMbqb0zJ89Ni 4RHLi+WV1JeLZqBOC1Puk+g6NMeD1Ny6Ng+vm6vltnNnQTQPaoGdB+8ViLd5jdXWBLgScM Uxv+TjcgKtcr/kVjZcqDiQJufwirc2Y= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 049F05C5870; Tue, 14 Jan 2025 13:09:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 05B11C4CEDD; Tue, 14 Jan 2025 13:10:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736860232; bh=vqMiHaYxo1OeV6vuFiLAKJFsyBYwVvIm77cJVle1WJ8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=l1nx/w9rZaUlfUPPBU47utVetUTnVL9ZexeuxPhebI4q9xOwKJB8QsH47uS2NgLHE kAZWXffsH5/p35zg8G1Wq3RbXzkrvqU7kVVq8mGf2F/olQvWByKXsi7S7/GrpG4Voa VvBgg9qe79KdwzK/nV30u5dqZYsiwRaCjJzTejZsJHkniACy98wD4emz4ZadTlhvcJ gobdeWehypQ5eW5l4w0NMcXhSYhLvQyliQPrA3ROUhqP+ReivN07AfVjV11Hz1m51G IU9uKWJ8M/PiSGRBEy7Iy98LL5wVIY6fYcJO3P4aGmvKdtc3knrQDy/+3r4lQbSLYp sQhGV9ki860XQ== Date: Tue, 14 Jan 2025 14:10:21 +0100 From: Mauro Carvalho Chehab To: Jonathan Cameron Cc: Borislav Petkov , 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: <20250114141021.0b6f0856@foz.lan> In-Reply-To: <20250109183448.000059ec@huawei.com> 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> <20250109142433.00004ea7@huawei.com> <20250109151854.GCZ3_o3rf6S24qUbtB@fat_crate.local> <20250109160159.00002add@huawei.com> <20250109161902.GDZ3_29rH-sQMV4n0N@fat_crate.local> <20250109183448.000059ec@huawei.com> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.43; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 7DAE94001E X-Stat-Signature: qwc1joywdbqrw81qjcyq6zz6yagnxmoc X-Rspam-User: X-HE-Tag: 1736860234-195608 X-HE-Meta: U2FsdGVkX18eTZY8eaBllhWJNPKMWADQniztC065WrZ7VSOWuVULlGkTtMvuGi+EbgIz2tx4X9mHdNDa8f0/v3vXHoePjbVlxznPLpvkHSgse5dWhy2mBScBEyx9cE42c1FaCfomKHaJ78uc4+RMx5ZSqiFYT5uSlig0aHW53Voiub1Pr2y6zkB/a4uVcVZ/aF0PHS3dCh5YDeiUuu9DqnAJh5NjtCCXN9U14BqzALnNR+mi6Z0lm9ij0f4kY5vXjlLbFmbg++BTcfn+WEqnb35C0ymmBvqHd10iY5294lRfijyfyY3ylczjkH5xSYIIO49muoyR0Cf0J27eiuWsajLanHuaqZCO/5FpxmZf0kP0qgJ1Q/6PiIZjfTv/eBgXMyjM6SFuC46bZeJiRj5ftD2hcpV7ATvakI+1mNVqhjtY6/5u+0pzP94HAGd8fc2RcRt/okhtjJbD/EqzsG6vnUE0f55q841y+LtBNLwxsIjMIos7+dca/BGiOZFNGcu3l7RMgqV3CZpCdiVWT7wDN84S8k6oA4yj1RPzFQW6AJTvmLPyDdn4qL9lmaurCFyhTXEMnbtXVmday+DmnqD8VTOMwJXudzuRam4MceiQwJ4qkyF32MS9jAV7JAT3xVFZ4YJulA4Epwk0PCd9bnMCiPRmmzN3/uIBUF8pIF7LQ3FMGlgklMNL241j+xaoq7zYn9cFOnjOJJpb9hFIHmFcDSbLVNKJ0Vc89Ayq7BNbcSmRF+SsFHJYZtb1XPkITYBky+C9eupi7Uuit6+D1x1h7Bz/d+ydF4cCA5h7S2raakpfjZ1A45n4NKtXVO23hgDfSfQ1z0TDop/qz01ocmbVVg1CZ1P7LHE07Au3ke+0eGdR2VZrre5xse8UBw/PJXve2/WssqMb9qs1UxbczqxyZRirPaSPggrjM9eigoNcoqYqPYXsGsMh2wZCQ3LSe8ZNUo/VqUJOlI/wK+cqiPp t2HZ1Ucv ZJC5YiokOCY63X/HSTQlQUz1Wk3WNFH1NgZcuL1ehTF9RM43UXXK5h9J42l12Zhr1DhE4kLVBvJ20ttFvHvlmdfXCeQLZZbNI2Dk0/Ffm4K1Sar6mL8guYfP7olJmzhnGUsT0DcDJChibyOWErNN/OP2qCwpr49zJtOZcCRLPLFtGl/7XpiAiZ26o6+AYNm1BV/wNwJqvZmRMiofrq8ssT1K/K5gntO2QKlFys+/M3SD5h3LoROK+QetDYOdQe7ZfEpymS7eEFy+c4sMVjuYiShoeBRd5sc/0ZCeYU6TB79OAMpmd1cyUqWdru4bGFACs6JbPSjcJHfwHMsj2RLGvZ7KayD/GiHdoqZQv X-Bogosity: Ham, tests=bogofilter, spamicity=0.000037, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Em Thu, 9 Jan 2025 18:34:48 +0000 Jonathan Cameron escreveu: > On Thu, 9 Jan 2025 17:19:02 +0100 > Borislav Petkov wrote: > > > > But then why do you even need the interface at all? > > > > Why can't the kernel automatically collect all those attributes and start the > > scrubbing automatically - no need for any user interaction...? Implementing policies at Kernelspace is a very bad idea. See, to properly implement scrubbing and memory sparing policies, one needs to have knowledge not only about the current Kernel lifetime (which may be a recent boot due to a Kernel upgrade), but also for events that happened in the past months/years. On other words, a database is needed to know if a memory error was just a random issue due to high cosmic ray activities (so, a soft PPR would be used - just in case), or if it is due to some memory region that it is known to have past problems, probably an indication of a a hardware issue - in which case a hard PPR would be used instead. If this were meant to be done automatically, CXL wouldn't need to send events about that to the OSPM. Also, different usecases may require different policies. So, better to let an userspace daemon to handle policies, and use sysfs for such daemon to to setup the hardware. Thanks, Mauro