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 7E8DFC25B74 for ; Mon, 27 May 2024 09:22:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EEABF6B0088; Mon, 27 May 2024 05:22:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E9B5D6B0089; Mon, 27 May 2024 05:22:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D3D186B008A; Mon, 27 May 2024 05:22:33 -0400 (EDT) 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 B98816B0088 for ; Mon, 27 May 2024 05:22:33 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 5DE10814B4 for ; Mon, 27 May 2024 09:22:33 +0000 (UTC) X-FDA: 82163635386.16.6F0D119 Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) by imf12.hostedemail.com (Postfix) with ESMTP id 5B3894000C for ; Mon, 27 May 2024 09:22:31 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=SPBZriHQ; spf=pass (imf12.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716801751; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=T0xBExIPLlnb73V0TN4uBsw1poWCW7XSDlsFHChb7DM=; b=bwlo93VQGoE4majSWKQP/c+m5sa0O8jQXrIz1OORjAxwOYVhhYysykPP5zeeSckb+tCgvH E/rTd6pl6gDpp3OvAfmSqPATZ4FyMxxcLgDMmVOnR2mfISJc6TkjzuueRkyCRb9pFNbVUF XG2+eIMKboRN2vFGaX0JVzf/aH4ZvZw= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=SPBZriHQ; spf=pass (imf12.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716801751; a=rsa-sha256; cv=none; b=u4jlRokVTazxdS25Yy8hYqtpHZP6cqteOKHskljaK+fTUnOEpsI0Szl5u530Iw8PFQlv7P P7NxMgs9u3DkzgXvSVZ/uJU5TWpndmHDXNzYmiNQehT4uEptx+qZb8BA2J60QeYzNmhYHs DEvl+0cPA9Ant/hWBRoZPPJ2Q+z/q6U= Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 7201740E01E8; Mon, 27 May 2024 09:22:28 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RYjAB7Wc3NWx; Mon, 27 May 2024 09:22:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1716801745; bh=T0xBExIPLlnb73V0TN4uBsw1poWCW7XSDlsFHChb7DM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SPBZriHQF7lKX5IFE2i7S1WHgpw/e2ZgDazXBq2Ne56WAW5uru0h+D/KZXOPaow1P FHipNPfAwwjOQbjng7shfjAA0cwUnWZ3jtcBFYS6Is/DGJ2O0rDVCkWUXAD+RWMRxc 61UBtzXkkk8FoB0eTYVOFKTsHyZiSAJO2cJSnM2Gqhjenoby2XPyH2j4AfwJTSX0uQ On6B/ja7boKIi1jWU0PrZSauop8+bPkkRszbZn6uflLP8SiAbTngYcS6t+0eRxFfYs 0SVkKasS/iskL50XTOEtGisylul6MNaQbrDx4qVFtkXEoH2Rp679HS3MJ/p/Hr4Eck /otdKmMO4CH5lQmzOP9kfXSxA4lD5+4lnghX8DDs7KJt1jidNFjQBtrHrj083/6lpe Akawq58ni+CJiL2kNQlWenuIZZleiXG3oITRIZ+Ydlb7L4pxaOwcbnBn1UXolrrfYh J7hOrSYRjZ+vRgJEV7jMQ5Dlxl6htEvaRFcEV+g9J1rJao8MxgPsmwxe0WmRlvxjjW lJOcTQr/90xnlE4LuW62QkLpUGIN6WRohLJEaQP2Qfbqw9OXBmRaMKFpstAdFmoG0W CSoPIFHshGcybeQ2Czc5N8HCQKWfCj6p9M/HeLlt0G9TC/V0Am0BKjRTH0sjyOmljv 6nCCho46U5kXTjKdcgyD3No0= Received: from zn.tnic (p5de8ee85.dip0.t-ipconnect.de [93.232.238.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 7B97F40E0177; Mon, 27 May 2024 09:21:38 +0000 (UTC) Date: Mon, 27 May 2024 11:21:31 +0200 From: Borislav Petkov To: Jonathan Cameron , Shiju Jose Cc: Dan Williams , "linux-cxl@vger.kernel.org" , "linux-acpi@vger.kernel.org" , "linux-mm@kvack.org" , "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: <20240527092131.GBZlRQmxwFTxxyR20q@fat_crate.local> References: <20240509200306.GAZj0r-h5Tnc0ecIOz@fat_crate.local> <663d3e58a0f73_1c0a1929487@dwillia2-xfh.jf.intel.com.notmuch> <20240509215147.GBZj1Fc06Ieg8EQfnR@fat_crate.local> <663d55515a2d9_db82d2941e@dwillia2-xfh.jf.intel.com.notmuch> <20240510092511.GBZj3n9ye_BCSepFZy@fat_crate.local> <663e55c59d9d_3d7b429475@dwillia2-mobl3.amr.corp.intel.com.notmuch> <20240511101705.GAZj9FoVbThp7JUK16@fat_crate.local> <6645f0738ead48a79f1baf753fc709c6@huawei.com> <20240520125857.00007641@Huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20240520125857.00007641@Huawei.com> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 5B3894000C X-Stat-Signature: nt7wobijjbac1xy7da4ytofe8x355161 X-Rspam-User: X-HE-Tag: 1716801751-795462 X-HE-Meta: U2FsdGVkX18R896Cvdu8RNVDfwgfdUiwtgEzYmFUOoqqaZ+PAA8nFCbKv+r39xeKToDK56IWocCvbSqWURtYDlAo87mSnJghfHvoQwY13TUuk1Ox64lM77Gqe9FlYejWPN//0Q/2u3pq1KRUuFJNEXv4YVtjRQ2jTFOtl+6DdIr6j5WWl32c960VcS/LSuntKZYCCI8t7zMPUxXjLmpTVsRWLZbdF+rwMT0fbMz6k7AYkh4wSNGJNH8T8pZpFNXfDvM7D8CywtuTGmyAFPGQHnzguXejJR7zaRQK2HF00XAQubs6DsY2gXd1G7y50Qy4JDYhtjyqVU3BWwF4dG550JOzaklC0NVxE8OovQpU4RbB3JoD91qtCfP2E0fqXQAg0+Dl6iOMeVcGY0mZ6FMRNz+02s1HNqt2s6+2n+j5iwsvf8g2NQAaAil8pe7a2P3f4YWLgxhYAlwN6GU3gCqcba5CrCxZyzxIDd1lbQ5lsfSEWTAdhBvpQOLFFdG5LutPYRrpzps5571b4Q0FLcfoS9/o1+sPyl2135HtMHc4ByzMn73gZu8eE+8SARRViAKwyOM3x/sbEJAu94rHT3sy5ZQ33UahV7t/GcS+6y+yjJIrKmuvWLMoWKGo4im7B9ktlXLsJj1RDoGMqIhVs21XYGyrlFrYhgmXxSdgKqcdeHXyADPYjpEKOcUW5Tc4LMT41OawXDP6Rp8VY7FfYh1SKvMc+bXmDU1WUzREkG3QzBxskkARHpTp+r2ByGORUyoFsNkmk9L1YXFWHYskMwQamasdVwN66IU7nEre5XeyirykodLtVMb4TyWOnsUi/jF5y14vgEFOt1DCwrKlnOnK6jC+a2Z/P0CfglfwwLyR9tcWIEsFBP3hwMxnBc0lOJYtzO+HJ/n2adYlSLH2coovbycwaQBnWlOZB3IhUH2Wi90Nb6ypWx/Q70bBZ6yZIjlOPlesNPod3jkSApH+f+9 gxak9jwX dlxyfjENfSXvtfkwp+MTBwvKJgeSvY8HmGBidfIJ6/REGcO3AFCLtm/p1hXRu3LM656P448L0CkzDOUdd1MCwAA0KnzvfXAQ+UPRwmivFyq+0+0OM6AokuPj8Gf9Qw/q6qcW8WgETzCtg9luIAJnkJGRcIYMtwL3GjkJjIm4KbGLrIPk5q1ThuaVI+17xk7WXcP8FYBp/Q9KmPqzUBWwNkhM1HtRMH3h2qa8Z5whVFLanD3aqqRi2dMBO1/g4oExDo8czJtrDC7VvMJevqB9A3NY8cLD5hmfDVjiasgBZQGwwQgA0x4/LRHXeTyDLRXuFdIsv X-Bogosity: Ham, tests=bogofilter, spamicity=0.001837, 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 Mon, May 20, 2024 at 12:58:57PM +0100, Jonathan Cameron wrote: > > Following are some of the use cases of generic scrub control > > subsystem as given in the cover letter. Request please add any > > other use cases, which I missed. > > > > 1. There are several types of interfaces to HW memory scrubbers > > identified such as ACPI NVDIMM ARS(Address Range Scrub), CXL > > memory device patrol scrub, CXL DDR5 ECS, ACPI RAS2 memory > > scrubbing features and software based memory scrubber(discussed > > in the community Reference [5] in the cover letter). Also some > > scrubbers support controlling (background) patrol scrubbing(ACPI > > RAS2, CXL) and/or on-demand scrubbing(ACPI RAS2, ACPI ARS). > > However the scrub controls varies between memory scrubbers. Thus > > there is a need for a standard generic ABI and sysfs scrub > > controls for the userspace tools, which control HW and SW > > scrubbers in the system, for the easiness of use. This is all talking about what hw functionality there is. I'm more interested in the "there is a need" thing. What need? How? In order to support something like this upstream, I'd like to know how it is going to be used and whether the major use cases are covered. So that everyone can benefit from it - not only your employer. > > 2. Scrub controls in user space allow the user space tool to disable > > and enable the feature in case disabling of the background patrol > > scrubbing and changing the scrub rate are needed for other > > purposes such as performance-aware operations which requires the > > background operations to be turned off or reduced. Who's going to use those scrub controls? Tools? Admins? Scripts? > > 3. Allows to perform on-demand scrubbing for specific address range > > if supported by the scrubber. > > 4. User space tools controls scrub the memory DIMMs regularly at > > a configurable scrub rate using the sysfs scrub controls > > discussed help, - to detect uncorrectable memory errors early > > before user accessing memory, which helps to recover the detected > > memory errors. - reduces the chance of a correctable error > > becoming uncorrectable. Yah, that's not my question: my question is, how is this new thing, which is exposed to userspace and which then means, this will be supported forever, how is this thing going to be used? And the next question is: is that interface sufficient for those use cases? Are we covering the majority of the usage scenarios? > Just to add one more reason a user space interface is needed. > 5. Policy control for hotplugged memory. There is not necessarily > a system wide bios or similar in the loop to control the scrub > settings on a CXL device that wasn't there at boot. What that > setting should be is a policy decision as we are trading of > reliability vs performance - hence it should be in control of > userspace. > As such, 'an' interface is needed. Seems more sensible to try and > unify it with other similar interfaces than spin yet another one. Yes, I get that: question is, let's say you have that interface. Now what do you do? Do you go and start a scrub cycle by hand? Do you have a script which does that based on some system reports? Do you automate it? I wanna say yes because that's miles better than having to explain yet another set of knobs to users. And so on and so on... I'm trying to get you to imagine the *full* solution and then ask yourselves whether that new interface is adequate. Makes more sense? Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette