Michael Kelly, le jeu. 26 mars 2026 17:53:27 +0000, a ecrit: > On 25/03/2026 22:57, Samuel Thibault wrote: > > Samuel Thibault, le sam. 14 mars 2026 23:13:55 +0100, a ecrit: > > > That's possible. For some memory-hungry packages I see several GB of > > > swap getting consumed, and little useful CPU time is spent, until the > > > build manages to finish, or times out. > > I had a look at the vmstat. The highest memory segment had all its > > inactive pages swapped out, but all the other segments had almost only > > inactive pages still in. I fixed the pageing out in gnumach, to select > > inactive pages from all segments before looking at activate pages. I > > believe that can help a lot when the last segment is small (and thus all > > the swapping happens there with almost only active pages...) > > i've looked at the changes you've made and it seems to me that it should > improve the performance. Perhaps if the improvement is significant the issue > with the vm_map locking might become less common to give us more time to fix > it. I'd be very interested in an update once you've assessed the new code in > action.
It's hard to tell. I have tried to run the mypy build, it's still quite slow, but it seems faster. Possibly its working set is simply really large. I guess it'd be simpler to just test with synthetic benchmarks which exhibit simple memory access patterns. But, yes, improving performance by lowering the swapping will lead to less triggering of swap hangs :) (which conversely is bad knews for reproducing it to be able to fix it) Samuel
