On 27/10/24(Sun) 20:01, Miod Vallat wrote:
> > > Wouldn't it be better to make pmap_collect() return the number of
> > > freed pages?  This is only actually implemented on i386 and it looks
> > > fairly simple to count the number of ptp pages freed in
> > > pmap_do_remove_86() and pmap_do_remove_pae() and have them return that
> > > number.
> > 
> > I'd appreciate any help with that.   However there are other archs apart 
> > from i386, what about sparc64, mips64, m88k and alpha?
> 
> Sorry to be late on this, lack of {spare time,bandwidth} as usual.
> 
> My own todo list mentions:
> 
>   * uvm_swapout_threads
> 
>      change the pmap_collect() interface to:
>      - have a return value telling us whether it has freed mappings or not;
>      - stop after N pages freed, where N will depend on how starving we are.
> 
> so I'll welcome any change compatible with this.
> 
> Note that however pmap_collect() does either way too much, or nothing,
> in the current state; so after the return value change is implemented,
> there will be work needed to make it work with a smaller granularity.
> 
> Passing the "number of pages to free" goal to pmap_collect() could be
> worth doing as well.

Lovely!  That's exactly the behavior of the modified bufbackoff() I sent
to this list.  It takes a number of pages to free and return how many it
freed.

This allows us to compute a amount of pages to free first then stop as
soon as it is reached.

Do you have an example of the pmap_collect() changes you're mentioning
for an architecture?