Hello,

Michael Kelly, le ven. 06 mars 2026 20:10:16 +0000, a ecrit:
> I thought that I would start a new thread to discuss issues arising when
> mach-defpager is not used when operating with high disk usage.

Yes, that should be fixed.

> When I run my build script without mach-defpager it locks the system quite
> rapidly.

That's "nice" since that allows to reproduce the issue :)

> Anyway, when the system locks up, a large package is being installed
> creating many dirty pages destined for my chroot ext2fs. pageout is
> initiated and threads within all 3 ext2fs servers (/, /boot and the chroot)
> are blocked waiting free memory. I've attached the relevant kernel debugger
> output to illustrate the detail but in summary the cause is related to the
> chroot ext2fs process ($task25):
> 
> 1) thread 21 waits for memory in vm_fault and so has $map25 locked

Locked? Then that's the issue. Having a lock while waiting for memory
would indeed be a sure path to deadlock. pmap_enter notably releases its
PVH and pmap precisely to avoid such deadlocks.

I however didn't see where vm_fault/pmap_enter locks the map?

> Is it possible for pageout to identify pages which are executable ? Perhaps
> it might help to continue searching for 'non-executable, read-only' pages
> which can be trivially reclaimed under these circumstances.

This would just be trying to cure the symptoms rather than really fix
the underlying issue. Better fix the issue than making the symptoms
rarer, which would mean making the issue even harder to observe ;)

> I don't think any of the above is really a surprise but what is surprising
> to me is how boralus manages to sustain lengthy operation without this issue
> arising?

I realize one thing: I have set the sync=5 option for the build ext2fs,
which probably helps with avoiding ample storms. But that's again only
curing symptoms.

> Why does boralus buildd run without mach-defpager?

Swapping memory is inherently a difficult thing, more particularly
so when writing to disk involves a userland process there
(rumpdisk). Possibly we have now fixed the issues related to swapping, I
just prefer to keep boralus out of potential issues.

> I'm trying to repeat precisely what boralus is doing in order to replicate
> the corruption. I can only reliably build large packages whilst using the
> default pager so would it be possible to enable the default pager on boralus
> and see if file corruption then occurs?

ironforge and mahler both have swapping enabled, and they do encounter
corruption too.

Samuel

Reply via email to