From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <140e7ec30709050133m1f9423asc21e5561abddcd97@mail.gmail.com>
Date: Wed,  5 Sep 2007 16:33:35 +0800
From: sqweek <sqweek@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] plan 9 overcommits memory?
In-Reply-To: <76c6f43793c4760d9049f52caf9a2608@quanstro.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <557b673255bf469340fec39ebc5ec647@csplan9.rit.edu>
	<76c6f43793c4760d9049f52caf9a2608@quanstro.net>
Topicbox-Message-UUID: b7d3f60c-ead2-11e9-9d60-3106f5b1d025

On 9/4/07, erik quanstrom <quanstro@quanstro.net> wrote:
> > Also, [swap is] broken, broken, broken on Plan 9
>
> but could you describe what antisocial behavior it exhibits and how one
> could reproduce this behavior?

 My cpu/auth/file server is a poor little headless P100 with 24MB RAM
(there's 32 in there but apparently one of the sticks is faulty). I
have a 192MB swap partition set up, man -P hoses the box (gs was the
biggest memory user IIRC). Actually, hoses is a bit misleading...
 I hear the box reading the disk for a time, then my drawterm locks
up, then it carries on with the disk activity, changes sound slightly
(guess it's into swap), and finally goes silent. drawterm is still
locked up, it's like something swap related is deadlocked or somesuch.
 Now, I'm sure, in the past that if I ^T^Tr drawterm at this point,
some time later the box recovers in a flourish of disk activity and I
can reconnect. But apparently this is not guarenteed as last night
when I tried it to get accurate timings it really was hosed, and still
dead when I woke up just now. I dragged a monitor over to it but my ps
hung, so I guess fossil or something else important bit it.
Unfortunately I forgot about ^T^Tp until just now.

 So yeah, I've probably got a decent test bed for swapping.
-sqweek