rmap is only about making pagout/swapout activities more efficient,
there's no stability issue to solve as far I can tell.
> The case of "system has more than enough memory" won't suffer
> with -rmap anyway since the amount of activity in the VM part
> of the system will be relatively low.
I don't see anything significant to save in that area. During heavy
paging the system load is something like 1/2% of the cpu.
> > And on the other case (heavy swapout/pageouts like in some hard DBMS
> > usage, simualtions and laptops or legacy desktops) we would mostly save
> > CPU and reduce complexity, but I really don't see system load during
> > heavy pageouts/swapouts yet, so I don't see an obvious need of save cpu
> > there either.
>
> The thing here is that -rmap is able to easily balance the
> reclaiming of cache with the swapout of anonymous pages.
>
> Even though you tried to get rid of the magic numbers in
> the old VM when you introduced your changes, you're already
> back up to 4 magic numbers for the cache/swapout balancing.
>
> This is not your fault, being difficult to balance is just
> a fundamental property of the partially physical, partially
> virtual scanning.
Those numbers also control how aggressive is the swap_out pass. That is
partly a feature I think. Do you plan to unmap and put anonymous pages
into the swapcache when you reach them in the inactive lru, despite you
may have 99% of ram into freeable cache? I think you'll still need some
number/heuristic to know when the lru pass should start to be aggressive
unmapping and pagingout stuff. So I believe this issue about the "number
thing" is quite unrelated to the complexity reduction of the paging
algorithm with the removal of the swap_out pass.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/