Subject: Re: OS2 question
From: Chee Yap <[email-masked]>
To: Vijay Karamcheti <[email-masked]>
Cc: Allan Gottlieb <[email-masked]>, Chee Yap <[email-masked]>
Date: Thu, 02 Oct 2008 14:10:59 -0400

Thanks, Vijay.

Vijay Karamcheti wrote:
> Chee,
> 
> I may be missing something here, so apologize in advance if I 
> misunderstood your message.
> 
> Your analysis of the stable state of the CLOCK algorithm appears to 
> assume that the 'use' bit on the frames is only set/reset by the page 
> replacement algorithm. In actuality, the hardware sets the use bit on a 
> reference to the page, with the page replacement algorithm only 
> resetting it.

You are right -- my example of decay of the use bits (i.e.
having a steady stead of one use bit being set)
was based on the assumption that each reference causes
a page fault.

> 
> In practice, one would expect multiple application references to happen 
> between two page faults (and hence invocations of the replacement 
> algorithm): Part (C) explicitly assumed this was *not* the case to keep 
> matters simple.
> 
> With the above clarification, I don't believe the steady state behavior 
> is affected by whether we resume the run of the CLOCK algorithm from the 
> most recently evicted frame, or the first unexamined frame.
> 

Steady state behavior is a function of the (class) of infinite
input sequences we are looking at.  In my example (or rather your
example a la part (C)), where every page reference causes a fault,
then steady state DOES have a different outcome:

(a) In one case, the steady state has exactly one use-bit turned on.
(b) In the alternative case, the steady state has all but one use-bit 
turned on.

Here is the proof of (b): assume there are n frames,
and the CLOCK pointer initially points to frame 0.
Let i=1,2,...,n.  I claim that after the first i page faults,
the bits of frames 0,1,...,i-1 will all be set.  But this
is obvious, by induction.

So after n or more page-faults, we will have the steady state I claimed.

This is interesting.  Unless there is some other process
that unsets the use-bits, we will get my kind of steady state.
For example, the use-bits might decay after a period of time.
The steady state (under certain assumptions) is then a fixed
fraction of the use-bits being set.

I initially thought that (b) is better than (a).
But now it is not so obvious to me -- any thoughts?

> That said, I would recommend (and I assume you are already doing this) 
> being lenient with the grading on this part: if students show some 
> understanding of the CLOCK algorithm and realize that the next fault is 
> always for the (one) page that is not currently mapped to a frame.

Don't worry, it does not affect my grading of this part.
But I propose to change your solution so that the more reasonable
approach (setting the clock pointer to the next frame at the
end of an eviction).  I will implement it unless you disagree.

--Chee

> 
> Thanks,
> -Vijay
> 
> Chee Yap wrote:
>> Dear Vijay,
>>
>> I starting grading Core OS2,
>> and have a question about the answer to the Clock
>> algorithm:
>>
>> First we reference address 3001, and this evicts page 4 in frame 2.
>> The CLOCK pointer points to frame 2.
>>
>> Next, we reference address 4001, and this evicts page 2 in frame 0.
>> The CLOCK pointer points to frame 0.
>>
>> All these are fine.
>>
>> The problem is that, in looking for a page to evict,
>> the CLOCK pointer ALWAYS starts the search from
>> the last frame that was evicted.  The "use" bit of this
>> frame is therefore immediately reset.
>>
>> With every page fault,
>> (1) you set exactly one "use" bit, and
>> (2) you always reset at least one "use" bit
>> (viz., the bit that was "set" in the previous page fault).
>>
>> It is easy to see that this will eventually reach a stable state
>> in which the table has EXACTLY one "use" bit that is set!
>>
>> I don't think you want this situation.  The fix is easy, of course.
>>
>> --Chee
>>
>> p.s.
>> For Part A, some students think "fd=3, buf=998" means
>> that the virtual address of the first byte of buf is 3998.
>> I now wish we told students that "fd=3" is not
>> used in the problem.
>>
>>