lkml.org 
[lkml]   [1998]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux-2.1.129..
On Mon, 23 Nov 1998, Stephen C. Tweedie wrote:

> So, I have still seen no cases where overall performance with no
> page cache aging was better than performance with it. However, with
> the swap aging removed as well, we seem to have a page/swap balance
> which doesn't work well on 64MB. To be honest, I just haven't spent
> much time playing with swap page aging since the early kswap work,
> and that was all done before the page cache was added.

What way does the balance go? Too much cache/buffer memory
can be 'fixed' by adjusting the settings in /proc/sys/vm/*
(yes, I know it goes against your principles, but some folks
need special behaviour for special-purpose systems anyway)

> On Thu, 19 Nov 1998 22:58:30 +0100 (CET), Rik van Riel
> <H.H.vanRiel@phys.uu.nl> said:
>
> > It was certainly a huge win when page aging was implemented, but we
> > mainly felt that because there used to be an obscure bug in vmscan.c,
> > causing the kernel to always start scanning at the start of the
> > process' address space.
>
> Rik, you keep asserting this but I have never understood it. I have
> asked you several times for a precise description of what benchmarks
> improved when page cache aging was added,

I mean the addition of page aging in kernel version 1.2.x.

Back then there certainly was a big improvement vs 1.1.x,
but unfortunately I was not really into kernel hacking
back then (I didn't even have a Net connection) so I
might have misunderstood things...

> And the "obscure bug" you describe was never there: I've said to you
> more than once that you were misreading the source, and that the
> field you pointed to which was being reset to zero at the start of
> the swapout loop was *guaranteed* to be overwritten with the last
> address scanned before we exited that loop.

Nevertheless I observed a much more stable and less thash-
prone system with my small patch included.

> swap_out_pmd(), there is a line
>
> tsk->swap_address = address + PAGE_SIZE;

Hmm, this means that it should work as you say. The
system seemed to be much more thash-prone however...(?)

> > This gives the process a chance of reclaiming the page without
> > incurring any I/O and it gives the kernel the possibility of keeping a
> > lot of easily-freeable pages around.
>
> That would be true if we didn't do the free_page_and_swap_cache trick.
> However, doing that would require two passes: once by the swapper, and
> once by shrink_mmap(): before actually freeing a page. This actually
> sounds like a *very* good idea to explore, since it means that vmscan.c
> will be concerned exclusively with returning mapped and anonymous pages
> to the page cache.

It is also what *BSD and OSF/1 seem to do. They have tuned
and balanced this system for the last 15 years so the system
should be rather well tuned...

> > Maybe we even want to keep a 3:1 ratio or something like that for
> > mapped:swap_cached pages and a semi- FIFO reclamation of swap cached
> > pages so we can simulate a bit of (very cheap) page aging.
>
> I will just restate my profound conviction that any VM balancing which
> works by imposing precalculated limits on resources is fundamentally
> wrong.

The reason for a ratio like this is to ensure that:
- there are enough pages that can be free()d at any time,
without us needing to scan the page tables, this also
serves as a 'buffer' for high-pressure moments
- pages will spend enough time in 'unmapped' mode to have
some serious aging imposed on them, not doing this might
cancel out the effect we want (multi queue semantics)
- pages that are used semi-often will have some soft faults,
always-used pages won't. keeping the soft-fault stats will
enable us to make better pageout decisions cheaply
- when a page softfaults (is remapped in from the unmapped
state) we can get below the wanted ratio and push out
something else, this gives a nice, slow and uniform page
aging system (especially when we observe a second chance FIFO
algorithm for reclaiming the page-/swapcached and buffer
pages, only breaking the FIFO style when memory is fragmented)
- keeping 25% of memory in unmapped state allows us to easily
'fix' memory fragmentation, solving that problem as well --
without having to give up the fast & cheap memory allocator
we use now
- the easy-free buffer will allow us to keep less free memory,
a few higher-order buffers should be all since we can free
cached pages (shrink_mmap()) pages immediately,
- this in turn might slightly reduce swapping, especially on
smaller machines

cheers,

Rik -- slowly getting used to dvorak kbd layout...
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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