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 DA61FC4345F for ; Sat, 13 Apr 2024 01:06:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4814B6B00A6; Fri, 12 Apr 2024 21:06:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 431AB6B00A7; Fri, 12 Apr 2024 21:06:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2F9956B00A8; Fri, 12 Apr 2024 21:06:20 -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 130646B00A6 for ; Fri, 12 Apr 2024 21:06:20 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id CA3AAC0F65 for ; Sat, 13 Apr 2024 01:06:19 +0000 (UTC) X-FDA: 82002717678.19.6A35F35 Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) by imf09.hostedemail.com (Postfix) with ESMTP id F1D6914000C for ; Sat, 13 Apr 2024 01:06:17 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=AcbKrxwN; spf=pass (imf09.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.179 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712970378; 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=MHmucI/H5NxibwlUQ0js8/JOPLCBsTS2p7VG0CvPNNo=; b=cv3QBrXfWHd5Y7RRPs9vlds2vzsqsuf7jD6bjV5KliugPH7T/VWyx15O5fJBHCImOz7ROw 2chuB8t4ABNjOz4Lp8/iBBKyh1Q0wD4Eb7CLt2C9iro156tQVe/zhWSHBuScPrI8lqglmk QOQsd9aWzOcR3zgr186e40UNVqsnL1E= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=AcbKrxwN; spf=pass (imf09.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.179 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712970378; a=rsa-sha256; cv=none; b=GHVZUhPEl29Htb9a2LG0WcGmiROf7eYhxCS2wzhicef42pbgQXVw2YUOFnuxjVGMyWjS4e nKPhxCozYJcIHwnumty1OZCq3Yl35XfuT+YQjHZxPvpsrUZCGntcBauXO1IQmN7tp6sf7a dsiivfVXdodkDxuDbsxKxpaFQOtHGCI= Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-2d48d75ab70so21159961fa.0 for ; Fri, 12 Apr 2024 18:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1712970376; x=1713575176; 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=MHmucI/H5NxibwlUQ0js8/JOPLCBsTS2p7VG0CvPNNo=; b=AcbKrxwNeJdTfo7GxedM62Zc5MEyq6vCs1q5ZvZvVw9y67QbriZJVQ1AF3DUBAa1Vc FuLCdfMDyocnbpaA8pueVrzHzq4GygR0ZHP6n1hkY8Otqt7A0i3FMtn5GcEIjrtUCXtY al+RPI+JSUhd6t4DvRyGX+HyO8jegdVFK8ejD4gKXz9I4AZpDU4YNqSukd2/4OoBFpce QWvNsCVDOe6F7LdKAgWIrnPIi7BBpHXpBrnYiL71RAZpFgTrMiNXOy/FzPNKZl/lliW7 so+IqK4T2zL0vYVMWYVj8Bo6+9I5i+ocr6woUkghNPhqMc6JMAoqMWxWq+rMj0tBYVJL mRHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712970376; x=1713575176; 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=MHmucI/H5NxibwlUQ0js8/JOPLCBsTS2p7VG0CvPNNo=; b=E5fkK98yasC+U8fyRxQhXWYEYhlf8e9OK6NBy2pYQpbCzXJEn1eiNSceW5zXNWXHeV gK+z4o/IPzXG1Q/+icVeDv04+8okCk2ZX72lY0OoEuf8t+328mSoJi43GJYq5goxfQv1 DqB2D/QqftAa6/PdLZ1I8I720m6sLqzMJek0ekINZJLDfydi/G7WHSt4GaHuf0vGNXJQ NH+vXaqRsKDqT/1tMzVQXQX6U2A60JDhVPmqn8ioEk+7AtheYMvVUwfwFi/WIwq6g0px uCe0YLL+gbSQsJ8U5f5dZALhSO4oV0lJkyncMmseheB4pDYLBmNPMwH8a04HoivGuabx RAOg== X-Forwarded-Encrypted: i=1; AJvYcCWLltY79SNDM0djaI0LbkxWOlqPHWlBhXD5pa83xobDkvFmBjNNHv4ydcEWNEXSR7iw0/k1s0vk3jG+A7sSMv5knoM= X-Gm-Message-State: AOJu0YwRwoh138lueyUr1mAWfVwi/fmZOnPSeVgMyR1ABzGQ20RRIa6D DEHcfY4T1t7zkR5jpsX0iGQACH2155PncEu9brpnJtpvsR2b6AUsJggYKruO0yGHsk5bqNRtHHx LQqcazORWF0JRYtLu70i9tf88TvWYaaLMhn4y X-Google-Smtp-Source: AGHT+IFpxB1heOrrx/VKM6QexHAFmFQpjYHMRq+COSAp1rnrwuNIOToge4I6KnTSQ3CbY3cdCojL2edeLrHQ+egw2yQ= X-Received: by 2002:ac2:430d:0:b0:513:5951:61a4 with SMTP id l13-20020ac2430d000000b00513595161a4mr2495959lfh.6.1712970375757; Fri, 12 Apr 2024 18:06:15 -0700 (PDT) MIME-Version: 1.0 References: <20240405053510.1948982-1-yosryahmed@google.com> <20240405053510.1948982-3-yosryahmed@google.com> <20240405152619.GA866431@cmpxchg.org> <7aec7b98-db81-4238-bdd6-afb69679f852@redhat.com> <69dcd33b-e8de-4927-93dd-d4ea22834a18@redhat.com> In-Reply-To: From: Yosry Ahmed Date: Fri, 12 Apr 2024 18:05:39 -0700 Message-ID: Subject: Re: [PATCH v2 2/5] mm: zswap: calculate limits only when updated To: David Hildenbrand Cc: Johannes Weiner , Andrew Morton , Nhat Pham , Chengming Zhou , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: F1D6914000C X-Rspam-User: X-Stat-Signature: do78s1xmpph3we9w6815wpyfbtsb77wa X-Rspamd-Server: rspam01 X-HE-Tag: 1712970377-995098 X-HE-Meta: U2FsdGVkX19iK34ZpNrv24KpuptOsvtk2+OKqHuEHzPSOMJoV9wSEmXbFZ2geZf9SL4T9doBj0r0rPTBElFbpX3jAU9IP9PwVarYndVMBgNtY1IhcA5SB38fBZ2jUjdtNeD6XSiCut8u2Vg2TrEV+6LOVLR58NZLbYZ4erhJxX4d51TfA+y2mQn3PaFdxN/Ss5N1cGWzHcvy7hGDitLnMJECaVR0ZxTpnYk9piL16mcAPq05UzCV3E7BFzYsPkPOJHyBq/SMpnd5ypoNC8h1vT5Lbr0/BZu3zHosWD4wL+BSwRgRr4tc8/nX/vYdNXhV4Ah+ns6uCe0BceVKOyZsiEQ4aOxle1VNhr+BxnILGtWGmws74ykK2IAa8bjceLkk3oENhr8bXrh2Nk19hu3O9wF4KhMvJ5BT2eCNb1eCUYL4D1QDrn9UCRrRhTF/drDtNbHHuVGX9sVfO8TmHK7RiQA7d5syA1oVjsDbMtmu9sgiL+I49NBPmzLQfuQeCBkmFqU8MZLF5bEz9gjWZ0Wz5CgzoOwupyPPKpXLgUQeIHeY8MO/n1+x9jiRXpJJV++BRlUgNmXv2+lT5GZJjFBYBsLOd9/P1PebHCOpEXcgRMq3+Lgg3nOYLsLOCRObrx6KsgisJILQc0fBBBdbYw6RKL6MvsfkhY1rA35g3D/AjbzonZhph5oi2NsgNHw5biqBfsJDX6ry73b6EethS6LbkKx8oQSNRAszLnqFOZCguioytim2ywXV9dvI42C4xj+TFN8BDf2z4BxuTWK9bDNBcXAzWquppZlZQmRWxaflRNtNu9fp11xs5nCcVxRzU5xDfZJr8678cwk/6JiqMuh42FzFqOoU6W2p9eczBGYL0repvr0UMQ+sf1DH/9qlWMU90l5xpc+EeCuVf+IckVh5pl2MAvkr+j89Wzt0AR+mwu24Q3sonNp3ReaRCut5mHUDMsW+VlMnzwhvjciuaG/ Ajxo0eip Ot71XFjjn1y0i8WY6fXO68hCGwnp1nF7g8qGcvdPLvL3Rn5ijfZNMM8ETzkHVTBOBG0oJHIV9+d7SpHFSUL3UfFfQpmPJObU/kC6D1iQRJ8pWAQd65RItQZeqs9H/uXi9qK7TSFMxCpTxmMbdtZOaqqIvPSlo+jVF0emPFAa/NpzRzanRtiNVf0y045GJWqSEjYs7ruNQaaUGdGz6tsMeUG94mqueFDLs/Im8xx4MoHCondPCMNn4raHSPg== 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, Apr 12, 2024 at 12:48=E2=80=AFPM David Hildenbrand wrote: > > On 10.04.24 02:52, Yosry Ahmed wrote: > > [..] > >>> Do we need a separate notifier chain for totalram_pages() updates? > >> > >> Good question. I actually might have the requirement to notify some ar= ch > >> code (s390x) from virtio-mem when fake adding/removing memory, and > >> already wondered how to best wire that up. > >> > >> Maybe we can squeeze that into the existing notifier chain, but needs = a > >> bit of thought. > > > > Sorry for the late reply, I had to think about this a bit. > > > Do you mean by adding new actions (e.g. MEM_FAKE_ONLINE, > > MEM_FAKE_OFFLINE), or by reusing the existing actions (MEM_ONLINE, > > MEM_OFFLINE, etc). > > At least for virtio-mem, I think we could have a MEM_ONLINE/MEM_OFFLINE > that prepare the whole range belonging to the Linux memory block > (/sys/devices/system/memory/memory...) to go online, and then have > something like MEM_SOFT_ONLINE/MEM_SOFT_OFFLINE or > ENABLE_PAGES/DISABLE_PAGES ... notifications when parts become usable > (!PageOffline, handed to the buddy) or unusable (PageOffline, removed > from the buddy). > > There are some details to be figured out, but it could work. > > And as virtio-mem currently operates in pageblock granularity (e.g., 2 > MiB), but frequently handles multiple contiguous pageblocks within a > Linux memory block, it's not that bad. > > > But the issue I see with ballooning is that we operate here often on > page granularity. While we could optimize some cases, we might get quite > some overhead from all the notifications. Alternatively, we could send a > list of pages, but it won't win a beauty contest. > > I think the main issue is that, for my purpose (virtio-mem on s390x), I > need to notify about the exact memory ranges (so I can reinitialize > stuff in s390x code when memory gets effectively re-enabled). For other > cases (total pages changing), we don't need the memory ranges, but only > the "summary" -- or a notification afterwards that the total pages were > just changed quite a bit. Thanks for shedding some light on this. Although I am not familiar with ballooning, sending notifications on page granularity updates sounds terrible. It seems like this is not as straightforward as I had anticipated. I was going to take a stab at this, but given that the motivation is a minor optimization on the zswap side, I will probably just give up :) For now, I will drop this optimization from the series for now, and I can revisit it if/when notifications for totalram_pages() are implemented at some point. Please CC me if you do so for the s390x use case :) > > > > > > New actions mean minimal impact to existing notifiers, but it may make > > more sense to reuse MEM_ONLINE and MEM_OFFLINE to have generic actions > > that mean "memory increased" and "memory decreased". > > Likely, we should keep their semantics unchanged. Things like KASAN want > to allocate metadata memory for the whole range, not on some smallish > pieces. It really means "This Linux memory block goes online/offline, > please prepare for that.". And again, memory ballooning with small pages > is a bit problematic. > > > > > I suppose we can add new actions and then separately (and probably > > incrementally) audit existing notifiers to check if they want to > > handle the new actions as well. > > > > Another consideration is that apparently some ballooning drivers also > > register notifiers, so we need to make sure there is no possibility of > > deadlock/recursion. > > Right. > > -- > Cheers, > > David / dhildenb >