Date: Tue, 20 Jun 2000 14:45:01 +1000 From: Andrew ReillyAtLake <A.ReillyAtLake@lake.com.au> To: Mike Smith <msmith@FreeBSD.ORG> Cc: freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Process migration (was RE: ACPI project progress report) Message-ID: <B7C8ABB31055D3118CB300902762A0E4471058@NEXUS6>
next in thread | raw e-mail | index | archive | help
> On Mon, Jun 19, 2000 at 05:40:30PM -0700, Mike Smith wrote: > > The real issue here is persistent system state across the S4 suspend; ie. > > leaving applications open, etc. IMO this isn't really something worth a > > lot of effort to us, and it has a lot of additional complications for a > > "server-class" operating system in that you have to worry about network > > connections from other systems, not just _to_ other systems. I was thinking about this a little more this afternoon, and it occurred to me that the system state management services that one would like for smooth "suspend" operation on laptops are very nearly the same as the process checkpointing services that one requires for process migration in a cluster environment. That sounds like a "server-class" application for this stuff. I know of at least one research project involving process migration in a cluster (at U Sydney, I think) using FreeBSD. Hey: wouldn't it be cool if, when you manually suspended your laptop, the processes waiting for user input would be suspended to disk, but the CPU-bound one running a simulation would migrate to your main compute server. It might even be finished the next time you logged in... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B7C8ABB31055D3118CB300902762A0E4471058>