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 6F291C4345F for ; Mon, 15 Apr 2024 18:31:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 04FC66B0095; Mon, 15 Apr 2024 14:31:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F41956B0096; Mon, 15 Apr 2024 14:31:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E09466B0098; Mon, 15 Apr 2024 14:31:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id C21276B0095 for ; Mon, 15 Apr 2024 14:31:13 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 4BFF6140726 for ; Mon, 15 Apr 2024 18:31:13 +0000 (UTC) X-FDA: 82012608426.03.36BEBE8 Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46]) by imf05.hostedemail.com (Postfix) with ESMTP id 6468210001E for ; Mon, 15 Apr 2024 18:31:11 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Xl243AKY; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.46 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713205871; 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=ooiKgKrfmVVf9meli4mQk0KMGxX8I7nqnD5XZE4i2o0=; b=m2p5Ue1hpHtYF6CrjWU8Ol4GqmjIaU34THImMZj+KRl4NJt6MqM/4tvqOiCPfQ7EocAT7I cRc6weY1wkxtts5SVze+utAphIacQTvSNuquPcxDjjveuck8nei66FIvhOOU8ztxPuf1lt ujks+w98t7w06CW88n+hI/AFRzwY4zg= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Xl243AKY; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.46 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713205871; a=rsa-sha256; cv=none; b=b3p11jsaMQnpmDvtNEDS3FIKmAOkDxEllqdChq08R1YQKTtOZyA3+JxdGhu1DZQkh5Llup AZhZ5NzpWCFBVUUbFXyy8lSdnhJXTJnigNLf7GWaTzF2Ko9jFYoBXQTk/Ur4aT0/LZl1rq Q82cyu80mzDes5Qu/9gy5CYk6f1aM6o= Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-a51a7d4466bso405112366b.2 for ; Mon, 15 Apr 2024 11:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1713205870; x=1713810670; 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=ooiKgKrfmVVf9meli4mQk0KMGxX8I7nqnD5XZE4i2o0=; b=Xl243AKYsqKirgYF1PhL62wAgFdv2DZ/uVIQkxO6qP6OLIWvhwu2UBexYd4UhWyRsQ TMo6MgIR26oXmYjkqNqETnLSIaY7NH6MggP1uhopYUkP4yfA4Adz7u2ZuLA4ykSl3VoH adGpfvUtcDHDZlFPaWZEDS2bM+WLxDXZXvOZEytJIKSmeQCEg9aQrwLKzFiJEH9Io3OU EMehjwZ0N9a/5pLqjvlhkgd7EJKepF4E9rdn3JEB6ZUdQEyx/fLUWmqn+VxueBRGlO/C ls1/Z+m2l2kL3NGeQBnknap8szFYDY6/1+jw/TyVTeMiTe51nNPAlIccudBjnVLciMzT R0qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713205870; x=1713810670; 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=ooiKgKrfmVVf9meli4mQk0KMGxX8I7nqnD5XZE4i2o0=; b=oBDsVxQZUOpy2vcRP1DyvmPswBt5RgadFXZRO382Do1kX9CV9TFfwzxMjuU8LOD9dk ULFPaZ6SIuxXRKGdiiLN24jxF94O3EXna5+eKjzvA90KArpaM+XR4mXZFKBzmEoUT3rV cwHzBUbhaZw1/W4j9vvxcyia2nGXjLQUdfRKcLae7VqMHjtoZzokj3WE61Pcos+1aXiC /D2hLefQWhVSmp07OzQxwY/hGgsii+CSxd9zYvg+7Hb1/54fmarUA52dCNuK6r9/IyVN yGEej5L94L1SQMXSsubLshRnTUi1gSwwm/wIMJm7WCenG7UwNnhguHA1khcDwFjHgT0M JPfQ== X-Forwarded-Encrypted: i=1; AJvYcCXanfH4YBEVz0s8f+GTHQZ1z2pRjVc7S3Y4niPIy8MXjDiIckDKqneveRn20BYKfFOMmCDgHcEz9F6hcfm088SzgnI= X-Gm-Message-State: AOJu0YzMXawI/Qfwbb7buzKFx3bcP3GXUEdrl3AziNU4B9WCuoUcD98x V1sxnMN6HFcOFE1MaSD+ojNxgPDCqnzvVRCJd9lwsGnax//s415wdw8zN6WkyguRoMf/vBsqRNU h3WC1hkD2zgaMsLgb7WAYSwbQtmUnZoADfw/1 X-Google-Smtp-Source: AGHT+IFmqRyB8N1jy/PHaBJGEIjnMGOrwq67XTdJuNETsU/iMnstWTpjwpiYg6YIif6xn7l4XYQWhubtI+8Hz7Isuyc= X-Received: by 2002:a17:906:c105:b0:a4e:cd5c:da72 with SMTP id do5-20020a170906c10500b00a4ecd5cda72mr7667793ejc.63.1713205869703; Mon, 15 Apr 2024 11:31:09 -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: Mon, 15 Apr 2024 11:30:31 -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-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 6468210001E X-Stat-Signature: yw1zbhz83n9ct5e9s3t5c9gesde1fuwg X-HE-Tag: 1713205871-325573 X-HE-Meta: U2FsdGVkX19HPxHU8AI++LpsVI3D5HpGMPnvoY6dLJj6b1Chal4iZMnKU/cOKXWeHE64hPC+xJAIuVYF3WIVvrwIoND58mWSYquP2u49Ik2Uadro//uQ0ODOGsHrXpb5S7VC3LEGV1+rqoCi6CL7h4gcrMW/m16Gw0vzg7ezGvqlU90D6FjEn/pQdEZLtK69mku1WFK0DigAT01MFJ5zPXCxnm6w/aqR1hL30ZUZKzGNXPSwGUoxNjekByKcQmXCXGDQ5Jou58RzTweP9I2g3y1OFjqz4T71ok1CywqlfGnH87eFLoRHVCVHG4IRnnNSfWYGwpszN/mnJVLM40dZkG9A2sqkq5Res1bIzPQYiu1N7r76/K7UCQmNtns38Ln7NoxqKmwhq6PS4DG16QtgLME/HRWQNYFYzCfxdsOZchh83ql0gW0oos7DZySVWuZSWQbCTWSrR/8dA+d45pklRUlY9sUAyMKtCh7vleSQJqN8EnMfvwCilDdlfffJrMqbXscyPlOtfs91hlhW1iKJr+489orsSGihkQ50+yR1ptTteyxjER9eFeOVQLEEbVn3GiUITP+viMgTyjv6buMftXCOzcRpEpzD1FsxKqUS8c2M6rc6nr5zQSWxOh/iEUsGNQhLOrfjo/qaZWZQB63UWAKFhuS83xYEswF0xn3oMYDOVXWxO0qb0wslbLTw3LEKLdISTwnLvzxYw1p0dW5rlKuD8fFAJY9JaYzfyhkUlp9EPgwzPs1eAKtnZn3nR6huAdF0IPkNOePCdfUj5yinOq0l+NQwQx9wE+Bj0StO/z8bMU87EW9z/25FcSGNtUXKrYfWe9yzPcMlOiEeO70uiTqMqePiHCWNi5ffPxiAw40zAvBQjonabEmZj1hCSKdUdUdznfHIe+VRbQ/gvsoGPYrgTKzSgtntP2AN7pAWiz7HMzcpVLQY7eVW22EQxKPI8bNSQWIWgXScrURwZIj ftaoOJYq O2GpBM7C8uh8Hc1jMaikXvhuXmaFTfK10gkrCYCcguaSmpR0knJ1YB848spTXN+VAsC246CgUsSBHHVkB/0OfrVJafr7qI0Zjz0px3LS53NssNps7n0AqJyKp8GJPeVmBByEKHJRdxBL1M1+JnYdG1EYtRb39+Le2Gnrbk+S8pgbG85v9tPatIn+zkxFPdKMGhB4K+YsmLRgOjumYv3rFe+w4fv9nrlzRKAB2myz+rli//lllnyNz7S23PA== 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 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 some = 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 need= s 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_OFFLIN= E > >> 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 qui= te > >> 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 othe= r > >> cases (total pages changing), we don't need the memory ranges, but onl= y > >> the "summary" -- or a notification afterwards that the total pages wer= e > >> 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 :) > > 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 use > > 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? 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. > > I'll look into the virtio-mem case soonish and will let you know once I > have something running. Thanks!