From: Yosry Ahmed <yosryahmed@google.com>
To: David Hildenbrand <david@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Andrew Morton <akpm@linux-foundation.org>,
Nhat Pham <nphamcs@gmail.com>,
Chengming Zhou <chengming.zhou@linux.dev>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/5] mm: zswap: calculate limits only when updated
Date: Tue, 9 Apr 2024 17:52:59 -0700 [thread overview]
Message-ID: <CAJD7tkb5D6Y5OMTzpHefYgSXbw7GdPtfjSp2=nBGjJFk99GP_A@mail.gmail.com> (raw)
In-Reply-To: <69dcd33b-e8de-4927-93dd-d4ea22834a18@redhat.com>
[..]
> > 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 needs a
> bit of thought.
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).
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".
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.
next prev parent reply other threads:[~2024-04-10 0:53 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-05 5:35 [PATCH v2 0/5] zswap same-filled and limit checking cleanups Yosry Ahmed
2024-04-05 5:35 ` [PATCH v2 1/5] mm: zswap: always shrink in zswap_store() if zswap_pool_reached_full Yosry Ahmed
2024-04-05 5:35 ` [PATCH v2 2/5] mm: zswap: calculate limits only when updated Yosry Ahmed
2024-04-05 15:26 ` Johannes Weiner
2024-04-05 18:43 ` Yosry Ahmed
2024-04-08 7:54 ` David Hildenbrand
2024-04-08 8:07 ` Yosry Ahmed
2024-04-09 19:32 ` David Hildenbrand
2024-04-10 0:52 ` Yosry Ahmed [this message]
2024-04-12 19:48 ` David Hildenbrand
2024-04-13 1:05 ` Yosry Ahmed
2024-04-15 15:10 ` David Hildenbrand
2024-04-15 18:30 ` Yosry Ahmed
2024-04-15 19:15 ` David Hildenbrand
2024-04-15 19:17 ` Yosry Ahmed
2024-04-05 20:23 ` kernel test robot
2024-04-05 20:29 ` Yosry Ahmed
2024-04-05 5:35 ` [PATCH v2 3/5] mm: zswap: refactor limit checking from zswap_store() Yosry Ahmed
2024-04-05 19:57 ` Nhat Pham
2024-04-10 2:30 ` Chengming Zhou
2024-04-05 5:35 ` [PATCH v2 4/5] mm: zswap: move more same-filled pages checks outside of zswap_store() Yosry Ahmed
2024-04-05 5:35 ` [PATCH v2 5/5] mm: zswap: remove same_filled module params Yosry Ahmed
2024-04-05 19:58 ` Nhat Pham
2024-04-10 2:31 ` Chengming Zhou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJD7tkb5D6Y5OMTzpHefYgSXbw7GdPtfjSp2=nBGjJFk99GP_A@mail.gmail.com' \
--to=yosryahmed@google.com \
--cc=akpm@linux-foundation.org \
--cc=chengming.zhou@linux.dev \
--cc=david@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nphamcs@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox