[lkml]   [2002]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:24    [W:0.103 / U:3.380 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site