At 21:07 8/19/95 -0400, Jonathan Shapiro wrote:
>In thinking through the EROS implementation, I've come across two
>detail questions. I'ld appreciate reactions.
>
>In the implementation I have in mind, there appears to be a potential
>conflict between the aging policy and the migrator. Specifically, one
>would like the migrator to have some reasonable assurance of timely
>completion, which imposes two requirements:
>
> 1. If the migrator is running, it must be able to allocate
> core frames for copying purposes.
> 2. If the migrator is running, it must be able to allocate any
> I/O descriptor data structures necessary to perform writes.
>
And in another messages asks:
>This is similar to the migration question, I suppose. When the system
>is under heavy, I/O oriented load, core space becomes pressured, and
>the end result is congestion. For the moment, let's assume that a
>decongester has been implemented.
>
>The question is: what policy or policies might be used to arrive at a
>balance between throughput and fairness, and where/how should such a
>policy be implemented?
>
Some of these assurences should come from whatever proofs you have that the only cause of starvation in the system is the scheduler's policy. For example, a simple disk arm scheduling stratigy is to always select the closest block next. However, this stratigy allows an active (set of) process(es) to keep the arm in one small part of the disk, starving other users of that disk. A better stratigy is to always select the closest block with a higher address. This stratigy results in the arm sweeping across the disk. An active (set of) process(es) can cause "hunger" by accessing every block on the disk, but no process is completely starved.
A lot depends on the specific implementation. For example, what kind of priority scheme do you have for access to the disk? If you have a policy that core frames can always be freeded (by writing their contents to the swap area), you move the critical resource from core frames to swap area space. If the amount of free swap area space falls below the limit needed to take a checkpoint, then you might have a last ditch policy of only running the migrator.
If you are frequently running out of I/O descriptors, then you should create more of them (After the next boot?). With a last ditch policy of only running the migrator, then it will be able to get a descriptor because nothing else will be using them.
Bill Frantz Periwinkle -- Computer Consulting (408)356-8506 16345 Englewood Ave. frantz@netcom.com Los Gatos, CA 95032, USA