From owner-acpi-jp@jp.freebsd.org  Tue Jun 20 10:07:00 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id KAA49058;
	Tue, 20 Jun 2000 10:07:00 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from orion.ac.hmc.edu (Orion.AC.HMC.Edu [134.173.32.20])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id KAA49052;
	Tue, 20 Jun 2000 10:06:58 +0900 (JST)
	(envelope-from brdavis@orion.ac.hmc.edu)
Received: (from brdavis@localhost)
	by orion.ac.hmc.edu (8.8.8/8.8.8) id SAA20250;
	Mon, 19 Jun 2000 18:00:03 -0700 (PDT)
Date: Mon, 19 Jun 2000 18:00:03 -0700
From: Brooks Davis <brooks@one-eyed-alien.net>
To: Andrew Reilly <areilly@nsw.bigpond.net.au>
Cc: Brooks Davis <brooks@one-eyed-alien.net>, Warner Losh <imp@village.org>,
        Poul-Henning Kamp <phk@critter.freebsd.dk>,
        Mitsuru IWASAKI <iwasaki@jp.freebsd.org>,
        bfischer@Techfak.Uni-Bielefeld.DE, acpi-jp@jp.freebsd.org,
        dcs@newsguy.com, freebsd-current@FreeBSD.ORG,
        freebsd-hackers@FreeBSD.ORG
Message-ID: <20000619180003.A15754@orion.ac.hmc.edu>
References: <20000620085531.A38839@gurney.reilly.home> <200006191630.KAA60652@harmony.village.org> <45525.961432574@critter.freebsd.dk> <20000620085531.A38839@gurney.reilly.home> <200006192301.RAA63461@harmony.village.org> <20000620101608.A38965@gurney.reilly.home> <20000619173055.A16200@orion.ac.hmc.edu> <20000620104924.A52825@gurney.reilly.home>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre4i
In-Reply-To: <20000620104924.A52825@gurney.reilly.home>; from areilly@nsw.bigpond.net.au on Tue, Jun 20, 2000 at 10:49:24AM +1000
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: acpi-jp 429
Subject: [acpi-jp 429] Re: ACPI project progress report
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: brooks@one-eyed-alien.net

On Tue, Jun 20, 2000 at 10:49:24AM +1000, Andrew Reilly wrote:
> The issue isn't with the size of the disk storage required, but
> with the mechanism.  Why dedicate 256M to a suspend partition, and
> invent a new process saving mechanism, instead of making your
> existing swap partition 256M larger and using the existing swap
> pager?

Because our swapper doesn't work that way.  Generally speaking, swappers
don't work that way anymore.  Systems that suspend to disk are a corner
case for FreeBSD.

> Processes do still wind up in "sleep" state, completely paged
> out, don't they?

Observationaly, no.  Unless I actually manage to run my system low on
RAM, none of my swap is used even with ~5MB Eterm processes sitting
unused for days.  I suppose if I let memory get tight, they might get
ditched in favor of disk cache, but I haven't seen that happen.  Someone
with a better grasp of the VM could give a more preciese answer.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
