On Mon, 28 Jul 1997, Urs Thuermann wrote:
> A couple of hours ago after 1.5 days uptime with 2.1.47, I noticed the
> system becoming slower. Since I had a similar symptom with 2.1.46
> before, shortly before I had to reset, I did a cat /proc/meminfo which
> showed
>
> MemTotal: 14724 kB
> MemFree: 372 kB
> MemShared: 4588 kB
> Buffers: 212 kB
> Cached: 3244 kB
> SwapTotal: 16116 kB
> SwapFree: 10108 kB
Nothing really strange here.
> This was with only the usual set of daemon (nothing large, not even a
> xntpd) and two emacs's running, each one with only one or two buffers.
> In any case the sum of free, shared, buf and cache seems too low.
> Just a few minutes later I got failed fork()s because of insufficient
> memory when I startet polling with uucp.
Ah, "emacs" (Eight(y) Megabytes And Continously Swapping)....
A fork() can fail because of "insufficient physically contigious" memory -
that is pages next to each other in core.
fork() needs these contigious-pages for its combined
kernel-stack-and-task-structure (they use to be separate, but were
combined for performance - they are both commonly referenced so having
them 'close' in memory helps the h/w). Also other structures allocated
during task creation need more than one page (eg. files_struct).
Of course, if the system is short of memory then there is a small chance
of contigious pages being found.
> I killed the two emacs process afer which cat /proc/meminfo showed
>
> MemTotal: 14724 kB
> MemFree: 2288 kB
> MemShared: 3600 kB
> Buffers: 1252 kB
> Cached: 4332 kB
> SwapTotal: 16116 kB
> SwapFree: 12580 kB
> What exactly do the number in meminfo mean? Can a physical page of
> memory in more than one or in no one of Free, Shared, Buffers and
> Cached? Must be that way, otherwise these 4 would add up to total.
> But how can a page appear in two of those 4 items?
MemTotal and MemFree are obvious.
MemShared is the combined size of all pages (in all address-spaces) which
are shared. Therefore, if a page is mapped by 4 tasks, it will be counted
as shared 3 times. To add an extra piece of confusion, this is only
true for anonymous pages - there is an exception for named, sharable
pages.
For named, sharable pages (that is pages which are read from a
file, and able to be shared with other tasks), each mapping is counted.
(If a named, shared, page is mapped twice it is counted twice. If it is
mapped once it is counted once). The counting happens this way because
these pages are also in the page-cache (Cache), and the code in
si_meminfo() doesn't allow for this.
Cached is the size of the 'page-cache'.
Buffers is the size of the buffer-cache (not including buffer-heads, which
are small enough to ignore).
> Is there a way for a page to get free, other than by a process exiting
> or decreasing its sbrk()? I would assume a page would never move from
> Cached or from Buffers to Free, but is taken away from Cached or
> Buffers only if it's reused in some other way, so it's still not Free.
> Is there some doc or intro to read about all this vm management?
Pages are moved around when memory becomes low.
Without dropping into all the details, Cached and Buffer pages move to
Free.
I don't think you are seeing a memory leak, just hitting the limitations
of Linux memory-management. There has been a few patches around to help
2.0.30 when it is underload, but I don't think they are the solution.
I'm currently working on an alternative scheme, which I hope will be
better at handling low memory situations, but no guarantees.
Regards,
markhe
------------------------------------------------------------------
Mark Hemment, Unix/C Software Engineer (Contractor)
markhe@nextd.demon.co.uk http://www.nextd.demon.co.uk/
"Success has many fathers, failure is a B**TARD!" - anon
------------------------------------------------------------------