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.