> Date: Thu, 2 Jul 2026 12:21:56 +0200 > From: Reinoud Zandijk <[email protected]> > > On Thu, Jul 02, 2026 at 04:54:00PM +0900, Takashi YAMAMOTO wrote: > > On Thu, Jul 2, 2026 at 4:04â¯AM Reinoud Zandijk <[email protected]> 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. > > > > with the cost of an extra allocation for the common case? > > (just a question) > > 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.
