Homework 3 Solutions

22C:116, Spring 1997

Ioana M. Lungeanu
Problem 1 Part A

The page frame table will also contain:
    - the access bits : Accesssibile, Read-only, Read-write
      We need to keep a copy of the real access bits here, because we
      are going to manipulate the access bits from TLB in order to
      get a page fault in the cases we have to update the Mark and
      Dirty bits from the page frame table.
    - the Mark bit ( tells whether a page was accessed or not)
    - The Dirty bit( tells whether a page was written to or not)

Problem 1 Part B


	if reference is to page not in TLB
	    if referenced page is in main memory
		bring the entry for page in TLB
                set access as Read-only(in TLB)
                set Mark bit to 1(in page table)
                select a victim page
                if page is dirty issue a write to disk & update TLB and map
                issue a read for desired page
                update TLB and map
                set access as Read-only(in TLB)
                set Mark bit to 1(in page table)
            if Read-only bit in TLB and attempt to write
                if Read-write bit in page table
                    set Dirty bit to 1 (in page table)
                    set Read-write access(in TLB)
                    Real access violation
            else    /* page marked as inaccessable in TLB */
                if accessible according to page table
                    set Mark bit to 1 (in page table)
                    set Read-only access(in TLB)
                    Real access violation

Problem 2 Part A


        if reference is to page not in TLB
            if referenced page is in main memory
                soft page fault for TLB update
                tell scheduler the calling process is blocked
                select page to replace
                update TLB & map for that victim page /or mark page as invalid/
                if page is dirty
                    enqueue a disk I/O request to write the page on disk
                enqueue an disk I/O request to read the desired page
		return to some ready process
            handle access violation


	if recently completed I/O request was read after page fault
	    update TLB and map
	    tell scheduler the blocked process is now ready
	    process as a normal I/O completion
	begin next disk I/O operation
	return from interrupt

Problem 2 Part B

    When a page fault is being serviced and another page fault for
    the same page appears there is no point in servicing it again.
    It is a lost of time, and it leads to having two copies of the
    same page in memory.  That is not only a waste of resources but
    may lead to inconsistancy problems for that page.

    When another fault for a different page interferes care should
    be taken for the global system variables involved ( like faulting
    process ID, page adresses) to remain consistent. Also if the two
    faults are simultaneous may be important in wich order they are

    These may be solved using a carefully mantained queue of requests,
    which takes into account the type of request(read or write) and
    for what page the request was.

Problem 3

    A scenario in which an infinite recursion can appear would be like

        A process faults for page A. The page fault routine faults
        itself for the page-table page containing information about
        page A. Then this page-table page is brought in the memory.
        The first call can precede now. Suppose it selects as victim
        page the newly brought page-table page, in order to bring in
        the desired page that originaly faulted. Since now the page
        needed is in the main memory we need to update the
        corresponding page table entry.  But this is not in memory
        anymore, and a fault occurs again.

    Of course if the replacement algorithm doesn't permit this ( to
    swap out a recently bruoght in page) this cannot happen. But in
    order to ensure this we can designate a zone of the main memory
    for page tables only.

    Of course, if a page table is too large and it cannot fit entirely
    in the main memory we are dealing with the pagination of the page
    table itself and we have a number of layers of page-tables. Through
    those the recursion can not be more than the number of layers if
    it is not the case described above.