Date: Sat, 24 Jun 1995 16:25:27 -0700 From: Matt Dillon <dillon@best.com> To: davidg@Root.COM Cc: bugs@freebsd.org Subject: Re: more on the paging thing Message-ID: <199506242325.QAA16868@shell1.best.com>
next in thread | raw e-mail | index | archive | help
Hmm... well, here's the problem I see:
* shell machine, 130 users on line, sitting at around a load of 8
* vmstat shows free pages steadily declining
* system does a spurt of paging
* 30-50 processes suddenly go into the 'w' column, the 'r' column
jumps to 30 as well, for about 4 seconds
* things slowly smooth out again .. back to normal after 4 seconds
* repeat 30 seconds later...
The problem is that whenever this occurs, EVERYONE gets glitched...
everything comes to a screaming stop for a few seconds, then picks up
again.
Obviously, some heavily used pages are being paged out when they should
not be!
The question is how to solve the problem. The system is not paging
heavily. It's got 128MB of ram and nominally about 12M free, which
drops steadily over 30 seconds to 2M or less, then the system does a
spurt of paging for a few seconds which bumps the free back up to 12M,
and so on.... What I would like to do is lock the pages associated
with the c shared library and a few critical executable text areas
(telnet, rlogind, and possibly tcsh) into memory.
-Matt
:> Ach! And here I thought I had found a problem... I didn't see the
:> pcount-- in the while() loop, so the end-of-queue problem cannot
:> occur.
:
: Yup.
:
:> Damn. But the second part of my suggestion still holds.... since
:> act_count is not touched when the system is not paging, the pages
:> that DO get paged out are determined in a problematic fashion.
:
: Well, we used to do it that way, but the overhead of scanning all the pages
:was prohibitively high. After doing some fairly extensive performance tests,
:we found only a very slight decrease in paging performance when adjusting
:act_count only when memory was short. On CPU poor machines (386's), it is
:higher performance to do it the way it is being done now.
:
:> So I would change my suggestions as follows:
:>
:> * keep the TAILQ_REMOVE/TAILQ_INSERT_TAIL in the else that I previously
:> thought should be taken out.
:>
:> * run through ALL the pages in the active queue once every 5 seconds
:> testing pmap_is_referenced() and adjusting act_count up or down.
:> If the active count hits 0, insert the page at the head of the queue
:> If the page was referenced, move it to the tail.
:
: Actually, this won't work very well. We depend a great deal on the pseudo
:LRU ordering of the page queues; the more we've diverged from this, the more
:the performance decreases. An examination of the act_count of pages shows why -
:the numbers are typically low on most pages, with a small percentage (say 10-
:20%) being relatively high. This means that there are "hot" pages that need to
:stay resident and a whole lot of other pages that need only to be carefully
:ordered.
:
:> This would work quite well... you can optimize it by keeping a pointer
:> to the last page with a 0 act_count occuring before any page with
:> a non-0 act_count, and use that as the insertion point for new pages
:> that are decremented to 0, inserting them into the queue at that
:> point rather then at the head of the queue.
:
: You can't do that. The state of the queues changes dynamically as processes
:free their private pages on exit.
:
:-DG
:
Matthew Dillon VP Engineering, BEST Internet Communications, Inc.
<dillon@best.com>, <dillon@apollo.west.oic.com>
[always include a portion of the original email in any response!]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506242325.QAA16868>