Re: uvm_swap compression patch

Taylor R Campbell <[email protected]> Thu, 2 Jul 2026 13:56:22 +0000
Newsgroups gmane.os.netbsd.devel.kernel
Message-ID <[email protected]>
> Date: Thu, 2 Jul 2026 12:21:56 +0200
> From: Reinoud Zandijk <[email protected]>
>=20
> On Thu, Jul 02, 2026 at 04:54:00PM +0900, Takashi YAMAMOTO wrote:
> > On Thu, Jul 2, 2026 at 4:04=E2=80=AFAM Reinoud Zandijk <reinoud@netbsd.=
org> wrote:
> > > as part of a compressed ram experiment I'd like to try, I've
> > > first cleaned up the current uvm swap support for I noticed that
> > > the support for encrypted swap became distributed and not
> > > logical anymore. In the attached patch I've contracted the
> > > encrypted support into the /dev/drum device and removed it from
> > > the specific swap support and callbacks.
> >=20
> > with the cost of an extra allocation for the common case?
> > (just a question)
>=20
> That should be patched in v2.

I think that's not quite right.  v1 did _two_ extra allocations when
the page daemon is swapping a page in (getiobuf and kmem_intr_alloc
for the ctx object); v2 reduces that to _one_ extra allocation
(getiobuf).  But the status quo is _zero_ extra allocations.

Much as it would be nice to put the encryption and decryption logic in
only one place, I think _any_ extra allocations in the page daemon
swapping logic is risky.