Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!umich!umeecs!dip.eecs.umich.edu!hudak
From: hudak@dip.eecs.umich.edu (Dave Hudak)
Newsgroups: comp.os.mach
Subject: Process Migration
Keywords: Shared Memory Multiprocessors, Multiprogramming
Message-ID: <1289@zip.eecs.umich.edu>
Date: 26 Jan 90 15:07:11 GMT
References: <643@umvlsi.ecs.umass.edu> <813@panix.UUCP> <76195@tut.cis.ohio-state.edu>
Sender: news@zip.eecs.umich.edu
Reply-To: hudak@eecs.umich.edu (Dave Hudak)
Distribution: usa
Organization: University of Michigan EECS Dept., Ann Arbor, MI
Lines: 21


	I'm curious about OS-level attempts to minimize write-sharing
in shared-memory multiprocessors (with multiprogramming) by restricting 
process migration.  Specifically, what I'm interested in is any OS's 
that keep track of a processes `state' (e.g. cache footprint, TLB 
content) and, based on that information, decide wether to 

	1.) Restart the suspended process on a different processor, since
the cost of migrating the process is below some threshold.  In this case,
how is the threshold determined?  Is system load taken into account?

	2.) `Hold' that process until the original processor becomes 
available.  In this case, how severely is load balancing affected?
What about fairness?

Just curious,

David Hudak 				hudak@dip.eecs.umich.edu
The Advanced Computer Architure Lab
The University Of Michigan
Ann Arbor, Mi