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 825AFC27C53 for ; Sat, 22 Jun 2024 16:49:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 50EE06B060F; Sat, 22 Jun 2024 12:49:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4BEA76B0610; Sat, 22 Jun 2024 12:49:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 386116B0611; Sat, 22 Jun 2024 12:49:18 -0400 (EDT) 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 18B466B060F for ; Sat, 22 Jun 2024 12:49:18 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id B9BF91A18D5 for ; Sat, 22 Jun 2024 16:49:17 +0000 (UTC) X-FDA: 82259109954.13.1263818 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.10]) by imf23.hostedemail.com (Postfix) with ESMTP id 437D714000B for ; Sat, 22 Jun 2024 16:49:15 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=RVUCfY15; spf=none (imf23.hostedemail.com: domain of ak@linux.intel.com has no SPF policy when checking 198.175.65.10) smtp.mailfrom=ak@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719074940; 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=r7J8zOH3s+XFkGsqLeKLhgPT9Z7LRXUgTGyuKIDJWWY=; b=OkleX0DjAgxPpqXDryWYIorkodXxXmuCNt/htNcINU8BQEylrF5pjjrfSr73Z+jIQAHLMW jCBYubEtv2ysscZ3w0UGHo5MVXQvnfgIqGPOo8VkUjU6SwBIMJmR8i8hYAt6NhNyTHasMb JO1vxRPyg3tJtWxGFEspPrmp5567CqQ= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=RVUCfY15; spf=none (imf23.hostedemail.com: domain of ak@linux.intel.com has no SPF policy when checking 198.175.65.10) smtp.mailfrom=ak@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719074940; a=rsa-sha256; cv=none; b=PnEelxJ4uAbJR7w/by04BtHbSfXQI30cKmCC/RlHmLEybpjE2PcwJfO/YBTuZLnaj1/Sic Hx/uQK/tROp2zoxJf/fhmjQXTwJXP2c+vQUnsqIL2bSR6whtjivOwbd/3g81FWya3uKfzI +55VwekfC8G/u6joWgoD9TKrPOUy+iU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1719074955; x=1750610955; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=JKS4BTNqhIWJKvQ52q0oKKZoT24gjwg0VxQiwj++Z3w=; b=RVUCfY15M+ig6AN7INSL4WbvVtWlWLnMZHW1LGPDS022OXr7dI7fE+AE DPkAcXAgaCK6FDx6KuYpj8Wzzc7xxqEn/v/Bb70Mo8TxDN5yZlDe8jo1o l5Uuy+IRiqzi/5BmINX6j5M3ezmUe6Qw/j5RBeetmIhZGogwrrbdTfxxq FsHfT6MiBfCOG6qXPLTuaeGxhk/ekuOVC6cSLfbD8X21NDqdGsRduAlh1 6rkhlOnTucngr5VliSomP0OtTDO/qjEHy+hK0yVxc2BDUPYBm/hukupi7 GymBstYnu972KwvEi+MC4drUnLh20dIN4Rbxt4uqiZr2ZK4q7mC5C3yyN A==; X-CSE-ConnectionGUID: 0jlDP1ODRMeaaNnmcBncdA== X-CSE-MsgGUID: BQ/yQ4qeT3Oe+R2LHBN3wA== X-IronPort-AV: E=McAfee;i="6700,10204,11111"; a="33554655" X-IronPort-AV: E=Sophos;i="6.08,258,1712646000"; d="scan'208";a="33554655" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jun 2024 09:49:13 -0700 X-CSE-ConnectionGUID: JDXf4qZUQ/+Cfdar1LhvNg== X-CSE-MsgGUID: iR1+Le1xTDCcBPEX8JE/gA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,258,1712646000"; d="scan'208";a="43552168" Received: from tassilo.jf.intel.com (HELO tassilo) ([10.54.38.190]) by orviesa007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jun 2024 09:49:13 -0700 Date: Sat, 22 Jun 2024 09:49:12 -0700 From: Andi Kleen To: Jiaqi Yan Cc: nao.horiguchi@gmail.com, linmiaohe@huawei.com, jane.chu@oracle.com, osalvador@suse.de, muchun.song@linux.dev, akpm@linux-foundation.org, shuah@kernel.org, corbet@lwn.net, rientjes@google.com, duenwen@google.com, fvdl@google.com, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org Subject: Re: [PATCH v4 0/4] Userspace controls soft-offline pages Message-ID: References: <20240620184856.600717-1-jiaqiyan@google.com> <87msnfusyw.fsf@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 437D714000B X-Stat-Signature: 77hb4tc4h3c3wc6th3wzitzp8ypparri X-Rspam-User: X-HE-Tag: 1719074955-834682 X-HE-Meta: U2FsdGVkX19EURhCLV01b5oD2aD6dwyDftHG837RNYDZYacaaMNIx9YyeNXAeOtOsftQ7VhLC0xmEYkVwlH02Lnoico1rrqwMQaOmjcEjZWntZ3O8FeHgw2cz4o6revM3Oya1Jo7XTy2v1EGnRcIQ3YqrjzYTaqWK/cHdcUZjIKTok308wrY/7SNRJl8NtKXb2uM0Spj6SlpoJhEc3kM9r216z651NO+1gh6kiC1lixImi3TYWQ3avW3ihPQiNijWtwG9P7yCNWX5prhXxaQN+pdZVhLWqmUbYNkkxhDlWL/7xMU3Z2xuFUjZIO+f1ax4ESkIb9z1p3JiJPBIqUmcftBcb74jzv2iKWYOGLasBzQ7VBobMGzyN9areHnK95Y+76pLJIj8QH7yfaUH85IoDhzdgW6IxDgulz2g7EGx3Xe3dl322b4DE/oPjIUeszk9FXbTVt6qPV1adKk9V4nt8sLERSdgu9jBb6JEoriPDpSJc9v21YeW5fXFcYq5HJzSE55V63vpjWAm9kth7VVfDT0x0u72g0j+W9bTe4DVxYxmhgZmZDQUkdxJaRtXJRoN4TBHtUeFL3c8GgN1Fvmp2aoDGIbdDGQ8pANR2zn5bGphOp3MIgBHDVC6GHMTv70kIKqSLsZjocI15of94Hfe2yxQeB1X8q9C9MSTPUlbD6UFoMzQvgZNLePwUlnjhDaITjX5fnI108hHaxU6dvAPRRkhZkSqJNGEStkZ7vLND6KuchKrHpM31pIUbztwHSXhd9La2dmjzMWUg5pE6oyfRVCa10AGRlFke3ngqi1jarPdc8eMLVLYNQmitjh8EjGUkhXJDNyrvddrvdQfI7btHJS2wBss0C+dWHikKdbIcgMGaR/g9NfVpgtfIa3Y//RY0HJwGUY5Ts3pJTOhteirZ00lbOBzRYNmLvHMa5O783IcqG1wWjZYq9OhYKuu7qBvxBowhKSu8p7QMkXEFc 18952c7S TO7pzvVqB9mZIZiEjJcXF5xVmSmvnvZ8nscZ7Uh3UFSV8R69qlpj9gWSRvWXaqK3QCCvXG7428UBRrV/uaYyz59LmIfUyJH79yBCcFxYylcEu9+WtRVzoBs/5EWSOyopzkMB8tYcgK+kGgjcBKUTX7DO1ms+9LpIRjDCScwyFySEukEfynaIq2lf+Wr0o9pCresezsw3boqoe3q19xpOogECcfug0Tnhe3mE+dUMgLMeb0YmPpkGJwBoGnNtGQM8X8hWBRCXw+rjPeGe9bf1taZ1/Tna5iQPjpY2Ek3XGzIfHGEbC/oi9Ee2P29lszs5icTyhzu7/UddpTmQE/8YaXwYaiBPSeTw3NtigASQsD7v9YOy1vM/2nTy7aa/LJ9zk43g7 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 Fri, Jun 21, 2024 at 04:53:41PM -0700, Jiaqi Yan wrote: > Thanks for your comment, Andi. > > On Thu, Jun 20, 2024 at 3:53 PM Andi Kleen wrote: > > > > Jiaqi Yan writes: > > > > > Correctable memory errors are very common on servers with large > > > amount of memory, and are corrected by ECC, but with two > > > pain points to users: > > > 1. Correction usually happens on the fly and adds latency overhead > > > 2. Not-fully-proved theory states excessive correctable memory > > > errors can develop into uncorrectable memory error. > > > > This patchkit is amusing (or maybe sad) because it basically tries to > > reconstruct the original soft offline design using a user space daemon > > instead of doing policy badly in the kernel. > > Some clarifications. I don't intend to reconstruct. I think this > patchset can also be treated as "patch some missing places so that > kernel doesn't soft offline behind the back of userspace daemon". > I agree with you (IIUC) that the policy for corrected memory errors > should exist in userspace. But the situation is that some behaviors in > the kernel don't respect that (they either have a reason to not > respect, or just forget to respect). enable_soft_offline is basically > the big button in userspace to block these kernel violators. It would be better to disable them earlier before they waste work tracking things unnecessarily. But yes it's a step in the right direction. > > > > > You can still have it by enabling CONFIG_X86_MCELOG_LEGACY and > > use http://www.mcelog.org or an equivalent daemon of your chosing > > that listens to /dev/mcelog. > > If I didn't miss anything important in > https://github.com/andikleen/mcelog and > arch/x86/kernel/cpu/mce/dev-mcelog.c, I don't think /dev/mcelog works > on ARM platforms where CPER is used to convey hw errors from platform > to OS. Yes or not on AMD even. -Andi