linux-kernel - Re: [PATCH v4 1/2] mm: store zero pages to be swapped out in a bitmap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJD7tkY+wXUwmgZUfVqSXpXL_CxRO-4eKGCPunfJaTDGhNO=Kw@mail.gmail.com>
Date: Wed, 4 Sep 2024 10:40:37 -0700
From: Yosry Ahmed <yosryahmed@...gle.com>
To: Barry Song <21cnbao@...il.com>
Cc: usamaarif642@...il.com, akpm@...ux-foundation.org, 
	chengming.zhou@...ux.dev, david@...hat.com, hannes@...xchg.org, 
	hughd@...gle.com, kernel-team@...a.com, linux-kernel@...r.kernel.org, 
	linux-mm@...ck.org, nphamcs@...il.com, shakeel.butt@...ux.dev, 
	willy@...radead.org, ying.huang@...el.com, hanchuanhua@...o.com
Subject: Re: [PATCH v4 1/2] mm: store zero pages to be swapped out in a bitmap

[..]
> > I understand the point of doing this to unblock the synchronous large
> > folio swapin support work, but at some point we're gonna have to
> > actually handle the cases where a large folio being swapped in is
> > partially in the swap cache, zswap, the zeromap, etc.
> >
> > All these cases will need similar-ish handling, and I suspect we won't
> > just skip swapping in large folios in all these cases.
>
> I agree that this is definitely the goal. `swap_read_folio()` should be a
> dependable API that always returns reliable data, regardless of whether
> `zeromap` or `zswap` is involved. Despite these issues, mTHP swap-in shouldn't
> be held back. Significant efforts are underway to support large folios in
> `zswap`, and progress is being made. Not to mention we've already allowed
> `zeromap` to proceed, even though it doesn't support large folios.
>
> It's genuinely unfair to let the lack of mTHP support in `zeromap` and
> `zswap` hold swap-in hostage.

Well, two points here:

1. I did not say that we should block the synchronous mTHP swapin work
for this :) I said the next item on the TODO list for mTHP swapin
support should be handling these cases.

2. I think two things are getting conflated here. Zswap needs to
support mTHP swapin*. Zeromap already supports mTHPs AFAICT. What is
truly, and is outside the scope of zswap/zeromap, is being able to
support hybrid mTHP swapin.

When swapping in an mTHP, the swapped entries can be on disk, in the
swapcache, in zswap, or in the zeromap. Even if all these things
support mTHPs individually, we essentially need support to form an
mTHP from swap entries in different backends. That's what I meant.
Actually if we have that, we may not really need mTHP swapin support
in zswap, because we can just form the large folio in the swap layer
from multiple zswap entries.

>
> Nonetheless, `zeromap` and `zswap` are distinct cases. With `zeromap`, we
> permit almost all mTHP swap-ins, except for those rare situations where
> small folios that were swapped out happen to have contiguous and aligned
> swap slots.
>
> swapcache is another quite different story, since our user scenarios begin from
> the simplest sync io on mobile phones, we don't quite care about swapcache.

Right. The reason I bring this up is as I mentioned above, there is a
common problem of forming large folios from different sources, which
includes the swap cache. The fact that synchronous swapin does not use
the swapcache was a happy coincidence for you, as you can add support
mTHP swapins without handling this case yet ;)