> Hi,
>
> On Mon, 29 Apr 1996 10:26:43 +0200 (MET DST), Matthias Sattler
> <m_sattle@informatik.uni-kl.de> said:
>
> >> As long as the working set does not change everything is normal, but even
> >> the smallest change results in heavy swapping (while the output of free
> >> looks normal).
>
> > In fact I don't see the problems with the original ncr driver, so it is
> > very likely that the bug is somewhere in the ncrBsd2Linux driver. Is
> > there something I can do to find out more about the nature of this problem ?
>
> This looks odd. I'd have said it was a sign of a memory leak in the
> driver if it wasn't for the fact that you are sure things are OK if
> the working set remains constant. Does this apply even if you keep
> working for many hours? Is it really the working set or simply the
> uptime which triggers the problem?
>
Stephen,
It seems to me that shrink_mmap() have some problem to shrink when
half of the memory (contiguous) is unfortunately filled with busy pages
and referenced cached pages, when we allocate a page for read
operations (GFP_KERNEL).
If we add the fact that tagged queue reorders disk operations and that
shrink_mmap scans the memory in ascending order, shrink_mmap() may more
often miss some unlocked referenced pages and have to wait the next time
to dereference these pages.
Bad news for processes!
Each time shrink does not shrink, a process may be swapped out.
That may happen even if half of the memory is freeable.
Does shrink_mmap() shrink from shrinking mmap or not?
That is the question I ask to me.
Unfortunately, I had some problem to understand the cache management code,
and I may be quite wrong.
Gerard.