Messages in this thread |  | | Date | Tue, 30 Apr 1996 23:43:04 +0000 (GMT) | From | Gerard Roudier <> | Subject | Re: 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 > <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.
|  |