[lkml]   [1996]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Bad 1.3.95 interactive performance (fwd)

On Tue, 30 Apr 1996, Stephen C. Tweedie wrote:

> Hi,
> On Mon, 29 Apr 1996 10:26:43 +0200 (MET DST), Matthias Sattler
> <> 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?


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.


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