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 24669C7115A for ; Wed, 18 Jun 2025 13:12:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B34006B0088; Wed, 18 Jun 2025 09:12:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AE44F6B0089; Wed, 18 Jun 2025 09:12:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9AC056B008A; Wed, 18 Jun 2025 09:12:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 87FBE6B0088 for ; Wed, 18 Jun 2025 09:12:05 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 088D4BF3C3 for ; Wed, 18 Jun 2025 13:12:05 +0000 (UTC) X-FDA: 83568559410.27.7481AF8 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf19.hostedemail.com (Postfix) with ESMTP id 52B981A000A for ; Wed, 18 Jun 2025 13:12:03 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=GozqKuXy; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf19.hostedemail.com: domain of pratyush@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=pratyush@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750252323; a=rsa-sha256; cv=none; b=S9tbQ+S0E/yAXYuphM9tEwOmuNw5JeVSX03+mYNIto/QGmkDAglf16aYHAsD4owvZ0qZKi 4HbD+rWPyuErOFd91dwBn22F5IzPHhcMPEwDt1R7Z8pNzD2B8eKi5EMCJO1cZPBi7dhqmX KP8OqGF7VqRXMBUir4ld8MzifackzSw= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=GozqKuXy; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf19.hostedemail.com: domain of pratyush@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=pratyush@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750252323; 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=s5qyzz/qBQpZoUuL9l+81lOuO/S3Lo8ObQXBuGDJkMo=; b=PLjsNH0Oc5hg5cfD6Tp/3cbtlUXQqDcuiJLrKfXPD2qclKW5UobEsHbxuTZmj0Ig+3kSbL T6oYT8zUQNZXvxcOg+cATa5erudprI7o73OANDYED58EMpAKflMi/jYCNoIL1cFVB5CbrT MXNnBfB4yQEDVOPsYSxWPcjIum7H9Wc= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 5A532629D2; Wed, 18 Jun 2025 13:12:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2CA03C4CEE7; Wed, 18 Jun 2025 13:11:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1750252322; bh=s5qyzz/qBQpZoUuL9l+81lOuO/S3Lo8ObQXBuGDJkMo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=GozqKuXyxjUgmHEhOYXLuI/y4m8rpsuTDKgLStZR7yoSnii9/Rf/S6+YbwlUnjzeJ r21kcjcCLL7SGOmlJ1y1lzExbZBJHW3sOgcdEsIQjMxHlC2hefQ7m5EmeksGYUnC3I 1iC0MFOnA7XEfodJTxoBdRjz18ca+DPjNXh7cdswd8lEqxYFc7Gylhr8xhOg2q24KO JFBIdww/zFK+lik5vw5TJO8cJHTBvRxLlggrRF/hccLVTvRLLwuayDWtGfNTo3NEcr VS7Phta3ho4Ph9cLqBRV/TVbThOaueLHdz+GJfVD9hktZqBlyJQgR+FHfQTxHld7aX GxNpyxYYXQg4A== From: Pratyush Yadav To: Pasha Tatashin Cc: Jason Gunthorpe , Pratyush Yadav , jasonmiu@google.com, graf@amazon.com, changyuanl@google.com, rppt@kernel.org, dmatlack@google.com, rientjes@google.com, corbet@lwn.net, rdunlap@infradead.org, ilpo.jarvinen@linux.intel.com, kanie@linux.alibaba.com, ojeda@kernel.org, aliceryhl@google.com, masahiroy@kernel.org, akpm@linux-foundation.org, tj@kernel.org, yoann.congal@smile.fr, mmaurer@google.com, roman.gushchin@linux.dev, chenridong@huawei.com, axboe@kernel.dk, mark.rutland@arm.com, jannh@google.com, vincent.guittot@linaro.org, hannes@cmpxchg.org, dan.j.williams@intel.com, david@redhat.com, joel.granados@kernel.org, rostedt@goodmis.org, anna.schumaker@oracle.com, song@kernel.org, zhangguopeng@kylinos.cn, linux@weissschuh.net, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, gregkh@linuxfoundation.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, rafael@kernel.org, dakr@kernel.org, bartosz.golaszewski@linaro.org, cw00.choi@samsung.com, myungjoo.ham@samsung.com, yesanishhere@gmail.com, Jonathan.Cameron@huawei.com, quic_zijuhu@quicinc.com, aleksander.lobakin@intel.com, ira.weiny@intel.com, andriy.shevchenko@linux.intel.com, leon@kernel.org, lukas@wunner.de, bhelgaas@google.com, wagi@kernel.org, djeffery@redhat.com, stuart.w.hayes@gmail.com Subject: Re: [RFC v2 05/16] luo: luo_core: integrate with KHO In-Reply-To: References: <20250515182322.117840-1-pasha.tatashin@soleen.com> <20250515182322.117840-6-pasha.tatashin@soleen.com> <20250617152357.GB1376515@ziepe.ca> Date: Wed, 18 Jun 2025 15:11:52 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 52B981A000A X-Stat-Signature: hic315fspe7yhkkq6rn7gisoqhi67czu X-Rspam-User: X-HE-Tag: 1750252323-496922 X-HE-Meta: U2FsdGVkX1+C1QqZgOlVFju0FzUL5kDsxTPelIhjITM/hZRPsf46ws/xRdlHcP/2LDnfjEp2JYVxZ7v1jjXTRH0W3wo1QLJGV9EYvns1QIJYM1B2ORZ80uMRIHZsgoe5IXwIengxl+El9HSmtJPiU0RbajY2w8auTfyNLQglKF4712gA1P8JKktge5Ta6i3Xg5c/fuhV0uSorvZuOYtu+yzNrnhP9mn2wRZ7fIy+UPF2qME2P4ORp5ZYoxK8YelgHS4yfdfxKBIoMaSBV7Nv0kEKo7eneMXnGvyD6+JRUK8old8FFx//Q2viXYKWL2KpqainnUK5gYSzbrDHyh8ylMPJJFg+ZcQ6hq3EO9LpCbMJpLONxaG+L5dZkgdoFN5EtHZzb09fogvAeVXTFxxM9gRqky+xY6dF/PjE4hLxaVU86EEMokmoWT2UgvZU50HEGOaljE49gv0R0WwszJSqXLXz2vMFXmujUF/xzqMy0DyENBV113i49cz146rWEgWm/a5waiSiQdIsIB2T5PHQGAcpls32o3hvobabFQ+pROMGVedKeNNpkOxCGf3v6wPtYRxNufMdKPcIhUhM0hDBXx81LTawjiomUa9HvqLMhw5cJpuL0JExHQNKFco4matpeDsBjwx8v55TAIbtszGLQzs3UvtUjNVo3kNRrKVPc69IPOlfvINoLNICWRFXErZZ0Akv9Dwd5npzXQ0Oma9e0q6+aEV/OemkfMU0KUbiaZMl7/614Vbrb85wyulInmGSB/row9hUiM1ZSaLrApqV/yA5cLbCoPBPJf16VGrZEpgQ9fsXeN3socdmxR2cUGQns/580usLdS/7YZgLMuZaowyR6jFWozD2SxlSa5hqNiR2NYDai8lpZ9x1eWywCe3KXRcsco/76hlzVIcOcgV9RQyThqz92/Fmh34uqgFoXs8AkGD5Iu+7m6aOsQtSrP/qbC+xVOu4sJ9GsnY78wK j71mZ2CJ +Xs76SQ86QQ4eY5zG20Nfp767NWuOdUfblmdzZJwRP2LlgeMCZ448HRc3isZ5SSZVRI7mRp36hTdTX1i7XzNVFrk+UOIps48cEYoGOcbtxH4yfCMcx6WB8BAmdUewANmLZ2W4wUjk+wRvdUIa+A7EoiEpTwh6xEvm3+tn+DCX5aXY4rhIBf5rK8+yyT4/bQ4TTWzb++fHVMDzdZzAbXIs7x+SZOBMLDnFnSJYiitc8ZJ9ZvpD6BpAVlOX0rCULaBmM7s1SdIyDgJTTf7wZ02cGaDqJml115dPI/Gg/zYtTvA3zkz4+dV1ibbMoDeUcZwmEcEumFZAMJY48iFwb/qcbs29HJKcB+H+l0pOmi4DzoNtrKi6apBHCxl4hPoSFxvGfuMDEkj/VonIyA4= 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 Tue, Jun 17 2025, Pasha Tatashin wrote: > On Tue, Jun 17, 2025 at 11:24=E2=80=AFAM Jason Gunthorpe w= rote: >> >> On Fri, Jun 13, 2025 at 04:58:27PM +0200, Pratyush Yadav wrote: >> > On Sat, Jun 07 2025, Pasha Tatashin wrote: >> > [...] >> > >> >> > >> This weirdness happens because luo_prepare() and luo_cancel() contr= ol >> > >> the KHO state machine, but then also get controlled by it via the >> > >> notifier callbacks. So the relationship between then is not clear. >> > >> __luo_prepare() at least needs access to struct kho_serialization, = so it >> > >> needs to come from the callback. So I don't have a clear way to cle= an >> > >> this all up off the top of my head. >> > > >> > > On production machine, without KHO_DEBUGFS, only LUO can control KHO >> > > state, but if debugfs is enabled, KHO can be finalized manually, and >> > > in this case LUO transitions to prepared state. In both cases, the >> > > path is identical. The KHO debugfs path is only for >> > > developers/debugging purposes. >> > >> > What I meant is that even without KHO_DEBUGFS, LUO drives KHO, but then >> > KHO calls into LUO from the notifier, which makes the control flow >> > somewhat convoluted. If LUO is supposed to be the only thing that >> > interacts directly with KHO, maybe we should get rid of the notifier a= nd >> > only let LUO drive things. >> >> Yes, we should. I think we should consider the KHO notifiers and self >> orchestration as obsoleted by LUO. That's why it was in debugfs >> because we were not ready to commit to it. > > We could do that, however, there is one example KHO user > `reserve_mem`, that is also not liveupdate related. So, it should > either be removed or modified to be handled by LUO. It still depends on kho_finalize() being called, so it still needs something to trigger its serialization. It is not automatic. And with your proposed patch to make debugfs interface optional, it can't even be used with the config disabled. So if it must be explicitly triggered to be preserved, why not let the trigger point be LUO instead of KHO? You can make reservemem a LUO subsystem instead. Although to be honest, things like reservemem (or IMA perhaps?) don't really fit well with the explicit trigger mechanism. They can be carried across kexec without needing userspace explicitly driving it. Maybe we allow LUO subsystems to mark themselves as auto-preservable and LUO will preserve them regardless of state being prepared? Something to think about later down the line I suppose. --=20 Regards, Pratyush Yadav