lkml.org 
[lkml]   [1997]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectAll these memory problems..
I might as well ask - are these memory problems supposed to be in 2.1.42?
I've been badblocking disks and running make -kj 16 a kernel at the same
time, and I've not quite seen what problems everyone has been talking
about. I have a buffer patch, and the one line page_aging patch, but even
before that, I never noticed any problems. mem=40M, I'll go try it with
mem=4M eventually..

Richard

On Tue, 1 Jul 1997, Dr. Werner Fink wrote:

> Date: Tue, 1 Jul 1997 13:30:57 +0200
> From: "Dr. Werner Fink" <werner@suse.de>
> To: markhe@nextd.demon.co.uk
> Cc: strasbur@chkw386.ch.pwr.wroc.pl, linux-kernel@vger.rutgers.edu,
> davem@jenolan.rutgers.edu
> Subject: Re: Page cache patch - 2'nd version
>
> > Ekkk! No!
> >
> > This changes the ageing of named (mapped) pages to be very aggresive,
> > which will result in many more page faults and file-system read/writes.
> > The faults may be hard (that is all mappings will have been undone,
> > and the page removed from the cache, so it will have to be re-read from
> > store), or soft (that is the page has survived reaping, and is still in
> > the page-cache, but this is still expensive).
> > The only guard left against reaping named (mapped) pages will be the
> > 'young' attribute of the PTE.
> >
> > Yes, it will mean that named (mapped) pages can be reaped easier, which
> > for some usage patterns will be a win (mainly those pages with a short
> > time in a working set. A reasonable example is a compiling a kernel).
> > And it will save CPU cycles in swap_out() - less deadend searches.
> >
> > However, if you compile a kernel on a box where users are (say) using
> > bash/vi, they will quickly find their working set of named pages reduced
> > (and quickly reduced again, if it does happen to grow). This is not very
> > friendly.
>
> Do you have run some tests? I'm not able to re-produce your statement.
> With the change of Krzysztof Strasburger I have much less I/O due swapping
> under high load and the system much more responsive.
>
> >
> > If you want pages to be reaped easier, use the page-ageing tunables!
>
> Maybe it's better to use age_page() to avoid aggressive aging and have a
> better compromise between a responsive system and the current used cache
> pages.
>
> >
> > NOTE: Named pages are given an initial age of PAGE_AGE_VALUE (see
> > pagemap.h - this is not a soft-tunable), which is 16. The configured
> > default age for anonymous (and shm()) pages is PAGE_INITIAL_AGE, which is
> > 20.
>
> After re-reading include/linux/swapctl.h and mm/swap.h I found that
> PAGE_INITIAL_AGE (swap_control.sc_page_initial_age) is set to 3 and
> MAX_PAGE_AGE (swap_control.sc_max_page_age) is set to 20.
>
> >
> > If swap is configured as a device, as opposed to a file, it is faster to
> > read/write an anonymous-page to/from swap than a named-page to/from the
> > file-system (there is less code overhead). So there should be a slight
> > preference to reap anonymous pages (they should be given a smaller initial
> > page age), but in the current implementation this is not true.
> > Why? The swap-device does not perform readahead. To do so, 'related'
> > anonymous pages (that is pages from the same vm_area) would need to be
> > written down in clusters - treated as a large page _when_ it makes sense.
> >
> > Memory management does need to be made more flexible in Linux. There
> > are already a few patches around. Unfortunately, to go much further MM
> > needs a re-work.
>
> A tested solution is needed for a working 2.0.31 :-)
> It should be possible to use the system during and after piping a big file
> to /dev/null or making a `make -j' in the kernel tree or run some other stress
> tests.
>
>
>
> Werner
>

-- http://www.digiforest.com/


\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.059 / U:32.740 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site