Messages in this thread | | | Date | Mon, 4 Mar 2002 15:05:45 +0100 | From | Andrea Arcangeli <> | Subject | Re: 2.4.19pre1aa1 |
| |
On Mon, Mar 04, 2002 at 09:41:40AM -0300, Rik van Riel wrote: > On Mon, 4 Mar 2002, Andrea Arcangeli wrote: > > > > having to scan two page tables to unmap it. In theory. Do you see a hole > > > in that? > > > > Just the fact you never need the reverse lookup during lots of > > important production usages (first that cames to mind is when you have > > enough ram to do your job, all number crunching/fileserving, and most > > servers are setup that way). This is the whole point. Note that this > > has nothing to do with the "cache" part, this is only about the > > pageout/swapout stage, only a few servers really needs heavy swapout. > > Ahhh, but it's not necessarily about making this common case > better. It's about making sure Linux doesn't die horribly in > some worst cases.
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/
| |