Article View: comp.sys.next.programmer
Article #732Re: Virtual memory devours my disk
From: Toon Moene
Date: Thu, 16 Apr 1992 21:00
Date: Thu, 16 Apr 1992 21:00
41 lines
2557 bytes
2557 bytes
In article <1992Apr14.120306.2121@cubetech.com> andrew@cubetech.com
(Andrew Loewenstern) writes:
[ ... Me writing about how simple it would be to repair the VM-swapfile
problems and offering help to NeXT to solve it ... ]
> Maybe you should just break down and spend $300 on a dedicated
> swap-disk. You would be able to fix your problem much faster than
> waiting around for NeXT.
Andrew, the whole point I was trying to make is that I don't have to wait
for NeXT to fix it, because I measure my swap space in advance (I've been
using my NeXT 12 Mb Color Station + Mathematica now for 6 months without
crashing it for lack of swap space). What I wanted to express is that I
want to help NeXT to overcome these problems, BECAUSE I THINK THEY'RE
QUITE EASILY FIXED. Don't be fooled by the Organization: line of this
post; before this life, I was a systems programmer at the largest academic
computer centre in the Netherlands - I've seen (and corrected - or worked
around) a lot of OS bugs.
Now the one of the ever increasing swap file is really easy, although the
details depend on the actual implementation of page-in, page-out and
page-not-resident-fault routines. The prime observation to make, is that
the problem is: having a lot of 'actually' free pages in a swapfile bound
at its highest 'page offset' by a non-free page. This page is used by a
currently active application, so we have a valid vm-map for it. Now the
point is that the OS should recognize that a lot of free disk space is
'helt hostage' by the relatively few pages dedicated to this one process
that doesn't go away, taking up the high-numbered pages in the swapfile.
This could be implemented by a simple heuristic. The action to take is:
make the few pages 'at the top of the swapfile' resident (either by
swapping them in, or by denoting them 'swapped in' because they weren't
changed), mark them as 'not swapped out' and truncate the swapfile.
'Look ma, no hands'
--
Toon Moene (toon@moene.uucp)
Kantershof 269, 1104 GN Amsterdam, The Netherlands
Tel.: + 31 20 6982029; Fax: + 31 20 6003411
No Disclaimers; a NeXT at home protects against this occupational hazard.
Technical Details
Message-ID:
<279@moene.UUCP>Path:
arc1-ca.pugleaf.net!sparky!uunet!mcsun!sun4nl!moene!moene.uucpReferences:
<1992Apr14.120306.2121@cubetech.com>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!mcsun!sun4nl!moene!moene.uucp From: toon@moene.uucp (Toon Moene) Newsgroups: comp.sys.next.programmer Subject: Re: Virtual memory devours my disk Message-ID: <279@moene.UUCP> Date: 16 Apr 92 21:00:28 GMT References: <1992Apr14.120306.2121@cubetech.com> Sender: toon@moene.UUCP Lines: 41