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 5B7ADC71157 for ; Wed, 18 Jun 2025 14:48:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 88EE16B0088; Wed, 18 Jun 2025 10:48:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 866B26B0089; Wed, 18 Jun 2025 10:48:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 77CEB6B008A; Wed, 18 Jun 2025 10:48:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 6E56F6B0088 for ; Wed, 18 Jun 2025 10:48:50 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E9A2BA1BF2 for ; Wed, 18 Jun 2025 14:48:49 +0000 (UTC) X-FDA: 83568803178.16.B7FBC95 Received: from mail-qk1-f182.google.com (mail-qk1-f182.google.com [209.85.222.182]) by imf01.hostedemail.com (Postfix) with ESMTP id EF8AF40005 for ; Wed, 18 Jun 2025 14:48:47 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=QPlPdHWC; dmarc=pass (policy=none) header.from=soleen.com; spf=pass (imf01.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.222.182 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750258128; a=rsa-sha256; cv=none; b=JqLqh9rRGBYhRyuoNORkSpfvrDfRIxqJ9lofzqh6KGSPWVaLVOKuwcarwYBKF3SbWK959y 8j/3S8kxVQF5tTHU7h5tSBRqwlRg0G/pg4S/TrGML+Cw3g+rIEKN3R1U1QJsQr5Zjkde5p bVEtgZ2oY9GrIbms1rwGh+Mhh0whGPg= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=QPlPdHWC; dmarc=pass (policy=none) header.from=soleen.com; spf=pass (imf01.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.222.182 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750258128; 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=R8VeINRsa1OxgNrKUKFRtGWzNViSlD55EzoK83kRcQg=; b=2WczI3wakNnxl8qIMdJytS408ED8WVFoOf4wPz99DZ76B7UknMhDrsNtTFvrLEms/XasOt 9Z+OMnEV2zzrZlMlrMJcbCldr/2ExkVnqtIPBOo3FvQ01B63yS8MvuvltCsgglV5NcKkrx UEajm+cmk43Vg93gEcU5S6mFV3ujUvQ= Received: by mail-qk1-f182.google.com with SMTP id af79cd13be357-7d094ef02e5so88720685a.1 for ; Wed, 18 Jun 2025 07:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen-com.20230601.gappssmtp.com; s=20230601; t=1750258127; x=1750862927; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=R8VeINRsa1OxgNrKUKFRtGWzNViSlD55EzoK83kRcQg=; b=QPlPdHWCWjvIp/KpJuRHgwtwpwen02PBhEf8UdrawkxAiEhEj+tgl/xpBC5M7NTWvh 72LMl9zDEauPuF/gZh47jUIGPoyUmtHljQUzQe76vXVPVyqsA+CxOUDzT/Jw08o7EIBN mujKxlQZbUE6FR0Ew0N/5BT68odMttzEhWlk4bkArHMPTqcMzet8czb2EK9zSJ62heii 7h/agCW5mo9TZ8QmySHZGlrKkN5RhyxJIcsn2WNdrKyc61LiCuS37XStBCDtMRJ1fBi9 iwX+/f7hmSarwhnqPGi1Qo5dLp/3iF76J/YlTnvSMmcwL4UBYIpR7fMElmSMBfHH9KaX zdOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750258127; x=1750862927; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=R8VeINRsa1OxgNrKUKFRtGWzNViSlD55EzoK83kRcQg=; b=F45+jGHgYgsby5pSi1R99SHQSx1KDHbTV9ESrTBgIMCRASJKKfJtnSZP5PxsWOx8Bx Uc1yzMzsGEJBMmFHueGi7aN4m3lb8G96ak14xcWqVd1e3Jn/gdn5suAIgYaXIgRRNa/7 +SSYMEYc4+oBCaA+XxExK5I6hwKYxgT4xLJghGlYljjhUO/z2XoAGmyX3g1Qn/cLQNBK WAVpZ5c6ml9bKwqu+eU+n/atD/AJkFC/u+2OXf4Oxqt9Rfs0E6aeOFCMUGiKGA584PvL hltrb1Hiq4KMAH+vv2w7S6nrirZKI+Kq+I9RZ0T4/WuuGMbsEhE2LF2cdPoO2qXc1mPb mzlA== X-Forwarded-Encrypted: i=1; AJvYcCXm7yCj4WahFfS6lN+iMPOi1M3+DNG3KACCvEnxq66Hzmsa7cuy2ZzFhUZgyDxkAA+Wvj3x2Bbmbw==@kvack.org X-Gm-Message-State: AOJu0YwmbCFyAd60qHeAEAgYJjepBOy7eS5aVmbiPlpl+YPCVqIKdQic UXByAK/fF8kGqNLgBC9zKS6Jc/DA2ulzjutuCOoWfmLgbesDgx6sSOrcfwMbJ9mn1ibfD5ktAOZ rLLyfHd9yXLHvITTMJS+OPdEDoD8VEl6tsOqo2HdGXQ== X-Gm-Gg: ASbGncuUvKL8HdKzo9HlkaNyFqRKsHF2axt6kGXcQ5Aj5maA5em5jq9U9X1J/DI3IF4 zahguXK4hJE4Tz5QP5CinYFbP8aPtedOtOLDDWvT28Tkji3fm5GVmkptiWpnBjUDRrYh3+JVA6C 9rTVLnsOZeV5CDvQPxy3Z7FLYo1MueajxQDXYYmMg2 X-Google-Smtp-Source: AGHT+IFZ+d0LIRnvuQ/PF2vSUV7/GsXTYRq155Ys06jbKx7qhTIQJlphjp1gq8ybYgdEc5Lt1pO8pAEIGzK2HNg9BCU= X-Received: by 2002:a05:620a:600d:b0:7d3:e56e:4fd8 with SMTP id af79cd13be357-7d3e93da631mr425634585a.12.1750258126838; Wed, 18 Jun 2025 07:48:46 -0700 (PDT) MIME-Version: 1.0 References: <20250515182322.117840-1-pasha.tatashin@soleen.com> <20250515182322.117840-6-pasha.tatashin@soleen.com> <20250617152357.GB1376515@ziepe.ca> In-Reply-To: From: Pasha Tatashin Date: Wed, 18 Jun 2025 10:48:09 -0400 X-Gm-Features: AX0GCFtpLB0oTRuEsFuAVbaG8Bvqsh21i0UCcwFP_32oEzA5tqSbuwcLuOtmBNE Message-ID: Subject: Re: [RFC v2 05/16] luo: luo_core: integrate with KHO To: Pratyush Yadav Cc: Jason Gunthorpe , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: EF8AF40005 X-Stat-Signature: 4afoc85738ahaazfwuh9acypbfffz1em X-Rspam-User: X-HE-Tag: 1750258127-147162 X-HE-Meta: U2FsdGVkX1+zijnpwJfi+fA3CT3fLs7u3ODKYitPApN9zvNL1SfPn3hG5nX2fJGfEL8BiRJQR2cR98yklyY3C58OgWxfSCYlB38oEx9JZoZA96biOnm8o3t0aBtPwb4Yvir2vFXehcuJXIEJyd8SYCBb6IVPbBMK2JaKrCELHFr+4Ec6ZMcnzXR6XODSnWIwecOJj0eppaBwVdUlGgLUgWZ+cv5LlUy2aG1lVlFB0SjtrlYwQnjgwBvWLpcZo41+a9hmc9idxxy5LYKKPj3J8XVgpffSBOdJ1sE6wayFD26hf/i92TnispJUEm0NDuReJWpmQNmGo7b0AiX5jLx+jn7UPxZNVSLsgsuG7jp9OuB62XqMMpi2s7NFkPE774oaDkEoBZEXA1lh0hA8LYcHI66LauEyq1cxBQxKJkx74i53S2svUard9YBIl9+IB3/keEOFyNADHXI+MPErYRE0wk3EerHK5yq/Q86B4QEhVy17BkF/eEqSvgkW5Ex8/w1z1NWeSSGQ2mb4Wpjd5IlRRHJAlTyLqWJosXXLoOifkRxpiOMaJPsbzjmeaiadnqmIUMSIFDIBghFujNuQDPQeleaBtSo/FBZ7pWaqaemzjD7DCp++ETNvAXwrVN+YtjsemH6Oxb8cO5F/oQ8Lw7XuZe27aQiqhfHg4KKb9ldYflTXUIFx8ghe3lmy8zu0cUGrYFAZnsft36DZdWvyyNLjsLT6WTvNxujb/iifvtXYHBmtoDZ5N7bGCNJm+uFOi+Ki2BRUUi8iYL0y/ic+/KXNnFFOjv1kv2W1l3l7vtaGQ747xyWNeeJEuzjxCoWBomhxyyFJuIM5qv+uj1shMeYSp0JBPMZtjOD6iGZkt0odPOCAw6sQYDGfeHin2y+2WehentLWPdc0eYsm0rXdVKYpuO4RduZkVlxwHUp3x7iEVpb/sA7GXymz/DlYH20a8FcphVhvhKjBmVYSKSLmYxQ xxlY2CWh VLMow9X34GMA99OGjVniDCbejAkn0OSY6mrQ+IB/LO4uBlRyq9Y4dtAS5CcdTvUfzBENf+f/fGtVt6gX3LGtFaLElui4qK18RwLjsPllrWAkonsUyQrqENrW/UBNpzyaB/99sp8GAHiouPaVtWnRph1aJMMG0Ym4sj7lWOS/Gxs+dHqXKIa7AzT4hdUz5sujB3gYJhHqRF+p97iXG7XFK3YBVQWTSjTC9F38WfU6gOKi4tQxVcMxKRyPmsJWrUJK27S2zO8KLldFH0L0T28j8X5jMEwPgk7WFkkeGWwOagrUMt9XqjDyJ5TqxRsJU9Md083ul/86p9KwAHH3159FXmLszpn+BSqkz0Z6W8sRzQhfhFmF7RF1uaS2XAPGrbPwLxb2OvMifHsvbfORa1GTcCp3X+0ADL8ghu0T91TXB014HcEEPUXDfIHtyafbgwouRcEmvt907FctsSWo= 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 Wed, Jun 18, 2025 at 9:12=E2=80=AFAM Pratyush Yadav wrote: > > On Tue, Jun 17 2025, Pasha Tatashin wrote: > > > On Tue, Jun 17, 2025 at 11:24=E2=80=AFAM Jason Gunthorpe = wrote: > >> > >> 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() con= trol > >> > >> 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 c= lean > >> > >> this all up off the top of my head. > >> > > > >> > > On production machine, without KHO_DEBUGFS, only LUO can control K= HO > >> > > state, but if debugfs is enabled, KHO can be finalized manually, a= nd > >> > > 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 t= hen > >> > 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= and > >> > 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. At least for now, it can still be used via LUO going into prepare state, since LUO changes KHO into finalized state and reserve_mem is registered to be called back from KHO. > 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. Yes, LUO can do that, the only concern I raised is that `reserve_mem` is not really live update related. > Although to be honest, things like reservemem (or IMA perhaps?) don't > really fit well with the explicit trigger mechanism. They can be carried Agreed. Another example I was thinking about is "kexec telemetry": precise time information about kexec, including shutdown, purgatory, boot. We are planning to propose kexec telemetry, and it could be LUO subsystem. On the other hand, it could be useful even without live update, just to measure precise kexec reboot time. > 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. We can start with adding `reserve_mem` as regular subsystem, and make this auto-preserve option a future expansion, when if needed. Presumably, `luoctl prepare` would work for whoever plans to use just `reserve_mem`.