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 6E878C4345F for ; Mon, 15 Apr 2024 19:18:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ACDBC6B0087; Mon, 15 Apr 2024 15:18:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A7DF46B00A0; Mon, 15 Apr 2024 15:18:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 91E7A6B00A1; Mon, 15 Apr 2024 15:18:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 70FD86B0087 for ; Mon, 15 Apr 2024 15:18:27 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2FCDB80408 for ; Mon, 15 Apr 2024 19:18:27 +0000 (UTC) X-FDA: 82012727454.16.0D3391A Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) by imf27.hostedemail.com (Postfix) with ESMTP id 57EB040015 for ; Mon, 15 Apr 2024 19:18:25 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=i0sNc7It; spf=pass (imf27.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.48 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=1713208705; 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=ALuNIUZS6wYf2/keSwqWw7ntqvL6NRxjJfhg0zFl8vo=; b=XTjn9+WrTMdXBh5wEpJaiW/lpiQ1eSFbhBdsNulEj4m5IHzjfmRLgFlDy8cQ6Kxzso5faD Cpdn/QLlKLiDHlV2LMCY0zP00K3OUDc1nIna6aCdithsvSn+zt0mJxXxrQXE4iW/6CibmQ ZQSwvvkPlSINnJa/TA1TK7eV5n+BXoA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713208705; a=rsa-sha256; cv=none; b=qWd05SL1BCTLMNpzrfrmjYl4PnLDH3ecH8vlsB3hdJl+36iInL8N0Kl1zEjH21Ka0Oa6Zi wj+hrijmlUiJ00mPD7Ec5hCONFSLbiRg9jOV9S/7/02nisqLKbqk4SqrC9bXrkrZNXC6qL krjKeGNBlUpYocTrzczbN5gT6+Rjt9A= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=i0sNc7It; spf=pass (imf27.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-a51addddbd4so420882566b.0 for ; Mon, 15 Apr 2024 12:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1713208704; x=1713813504; 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=ALuNIUZS6wYf2/keSwqWw7ntqvL6NRxjJfhg0zFl8vo=; b=i0sNc7It5SwBxwrIPcjF4RWaCtmALVGXrrkVErkKMTjNJvcNQOxPJGjxDzd6GTtm8y 6EUPfztuxk6DVFLS/0cFMq9fOdl/o3sxnqUH1L/Hpxg8BeU0KwTtObp5Bc9kCN9MZ7yf 3klEM9TPPTQJ9sfg1BStGYvUny7gGUBNq7rIt8nUqDjF6cEumnChTjTX34VefczYnLDJ Go5avmFLto0NdstaBiLSS6MELH0ZvnhX0vYewpqi7mPP7xSda2PbUP7h0LaJoWGTiOWG VDfy9kVaDPnR6M+sER1gN7gTWgIcDsnDUT/9a2LGxSqmkZ5UIkwSoUorWuaIJPrpBVFx LADg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713208704; x=1713813504; 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=ALuNIUZS6wYf2/keSwqWw7ntqvL6NRxjJfhg0zFl8vo=; b=aRiXhQUgU2gUkpv0W204EuWcYZaE5wXIHBtPAEc+4TJMKyYPnvk/Fm5w93DWKK9PtV gLWFfdHA85FFT+bysiZWET9saVht5jPJ2F02jUDBFjV+0wVQk9kufmnSwcgDsliXeojf 7FJLPusmjpeZXts6VKxJDlvZA9+hVoCcAKuNZ7Jzffltcj5PaYIFgRs3f5s8080Tt0B5 cWPizP4HdhtX/bL9nmi5pxjQVrPZImXRtTpo9CigRdXox7hiYHWCmI5bnbb7n0xfsAUw 2ZWAmxhwMzoYTCdhA5WaMTzmvkNx4N8MSKC6OKn8u0PhDT+C15IMIlGYo8vX3UdS+X6T jVPA== X-Forwarded-Encrypted: i=1; AJvYcCVUwrzEt8uoOCn5KNqp7p5ilXlBtcaTr9onrpPnJqPlh5kt7KY1h5TeBnUMyKRpImYKzIppo4J+GnpW51zxGH4q9oE= X-Gm-Message-State: AOJu0Ywk5mNyLXn39FKGCQHRcaxlYMfj6+M+qMi28r1cciwTgZ8uobKh V9EXwOTwoXm7vIzahqWu2IBX7i6rwjfaXE26Eq2kDJe/1aeLoEQ3ejRLEeUCq/C3cmu2FfwBdVm 76p3uYYpv80+q3csAC8bFm9EIjk4ciRclHJE5NdzbyoakhBwso9MK X-Google-Smtp-Source: AGHT+IHKCkhaUIaCBrVZaX7MLiHQwQXRoDVNNDzRPPY70dSBbHyXa1c9PIqBRcGGWLmm0Lk046xfsLONk3Ydo7CxG2M= X-Received: by 2002:a17:906:68e:b0:a52:66f3:a9ee with SMTP id u14-20020a170906068e00b00a5266f3a9eemr2471348ejb.41.1713208703571; Mon, 15 Apr 2024 12:18:23 -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> <11e9143f-67c6-4d7a-827b-dd04043b6fa4@redhat.com> In-Reply-To: <11e9143f-67c6-4d7a-827b-dd04043b6fa4@redhat.com> From: Yosry Ahmed Date: Mon, 15 Apr 2024 12:17:45 -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-Stat-Signature: 5ccphoz1fryzmr8jwtmr8yjmm1xwtkqk X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 57EB040015 X-Rspam-User: X-HE-Tag: 1713208705-24515 X-HE-Meta: U2FsdGVkX1+3YQrP/tfevAU53Kv6ocDGEQRBLLCp0WTVy7gRQkVxqiaqFk1W6zdN/oaKll26c1tLuALTefRf/sybx1cuEp28R1nDjN8fQ7UvTHAQb8LQSp+JGsFavI1xNh2TscJLLUzek0j+rziKno3YfQvrvcjA0JK/vTrhXiFAsTT6pMY/1q50Ec/p/d64jubrnyjYTFK/27UNMbIkDNomW5n+8hr3688IrQNMKC+IkuuAEpTiYlVXttGR5fgYME+V+V9VCSpuNNHXCJhEyIYYkmywr+FMivZv5tZowfcpu0UOGMdas5WZhgGkQrWgIPPLZqTMinz+hSNtaA5ldSA3ptrZtEw3W4uqa7crJVfcgMnKRpi9Jyi15+dR+T0guJ8DWD5lTRhq7CKkyUY5QDK5g8NGjYCIqMLDMkrhmsVENpEzl9qAgvTHnLSUMYtQRIaJIHJCJn1F9Ea5LOhzjNkguX2GNhgSAtAI+JGdGehtI3yTJlExYQWuUObRVTALEKF9IRQIle5mKwKZHO94bLKX8HYxgs9a8QAB2/yo10HQP73Ncl4c8huMTSFuUzPfIzLoUtgu4U8OJafa9dXSuVUcvlEc8DPTn4W/zhmEgxM9uwsZdXivh47qYfnDbXkQFCwV73wYKdqN579SdvUN+hbDyR/+YBEgGu8J9O5qulC/Oe2nwYX8P5wqD8VJ3MjMCdzUVGGTtLzxf4PGvFijzoGRH02TcVYbWDIA6+eYLCCH8aJPTjgJCDZL+4KlS74VTL98ZBeEgbKXWUmlY96PIx1Osom13yazyF6OELwifaSsln6OW3bc4KJKPhaUMekIN9N34Wp8VgVDx1EW/1cm6vqqK3k/7BZ+5VpM/XUFUMybFgdwpK0gfKCmXg3smKpMncD7bcH1XKTJpIKKrwp8PuVaM0FWqys8+F6rRBmSJ3Ut5h+619ujPgbTAGFobI5oyzFtl1gOQHvGsfkwWgN ActRnlfn 669BcEPL4pHKiPu1+HJkfq8H3/AxkkSBFvQ4sMfFhrwAsd7k8i0fllsM3xcZCgoIhWYI800niuyw5Y41I2fM1rj/1PS1465x/Bs1IAmOlter7NCzYNvAeYgf8J2GyTY8GqjOoI3Mtfe1ZCV/5g3jTxT5bHaqNJSULf9sMsEOENstfIOXCGbZvT9EaZIbmHM5y+8bxwP3Xh5jDPzOuwycbm2/d2PEziDjB+FQDR5QGoO4WPwo8IYmcTdAjbQ== 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 Mon, Apr 15, 2024 at 12:15=E2=80=AFPM David Hildenbrand wrote: > > On 15.04.24 20:30, Yosry Ahmed wrote: > > On Mon, Apr 15, 2024 at 8:10=E2=80=AFAM David Hildenbrand wrote: > >> > >> On 13.04.24 03:05, Yosry Ahmed wrote: > >>> 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 som= e arch > >>>>>> 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 ne= eds 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_OFFL= INE > >>>> 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 usabl= e > >>>> (!PageOffline, handed to the buddy) or unusable (PageOffline, remove= d > >>>> 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 q= uite > >>>> some overhead from all the notifications. Alternatively, we could se= nd 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 ot= her > >>>> cases (total pages changing), we don't need the memory ranges, but o= nly > >>>> the "summary" -- or a notification afterwards that the total pages w= ere > >>>> 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 ha= d > >>> 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 :) > >> > >> Oh no, so I have to do the work! ;) > >> > >>> > >>> 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 us= e > >>> case :) > >> > >> I primarily care about virtio-mem resizing VM memory and adjusting > >> totalram_pages(), memory ballooning for that is rather a hack for that > >> use case ... so we're in agreement :) > >> > >> Likely we'd want two notification mechanisms, but no matter how I look > >> at it, it's all a bit ugly. > > > > I am assuming you mean one with exact memory ranges for your s390x use > > case, and one high-level mechanism for totalram_pages() updates -- or > > did I miss the point? > > No, that's it. > > > > > I am interested to see how page granularity updates would be handled > > in this case. Perhaps they are only relevant for the high-level > > mechanism? In that case, I suppose we can batch updates and notify > > once when a threshold is crossed or something. > > Yes, we'd batch updates. Thanks for clarifying, looking forward to your changes :)