Browse Prior Art Database

Microkernel Extension for Dirty Time Limit

IP.com Disclosure Number: IPCOM000112174D
Original Publication Date: 1994-Apr-01
Included in the Prior Art Database: 2005-Mar-26
Document File: 2 page(s) / 107K

Publishing Venue

IBM

Related People

Copeland, GP: AUTHOR [+4]

Abstract

Most file and database system pagers promise that no user or meta data will remain dirty in the cache for longer than a specified time. There are several ways that this could be done. The following describes these along with their advantages and disadvantages:

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 48% of the total text.

Microkernel Extension for Dirty Time Limit

      Most file and database system pagers promise that no user or
meta data will remain dirty in the cache for longer than a specified
time.  There are several ways that this could be done.  The following
describes these along with their advantages and disadvantages:

1.  The pager could periodically issue a memory_object_lock_request()
    to return dirty pages without flushing for all memory objects.
    This is simple, but causes pages to be returned too often (a page
    may have just gotten dirty), and causes response time problems.

2.  The response time problem in A above can be improved by
    distributing the lock requests over time (e.g., cleaning fewer
    memory objects more often) at the cost of more complexity.

3.  All write accesses go through the pager, and the pager keeps
    track of what memory object pages get dirty and when.  This
    enables the pager to clean only those pages using
    memory_object_lock_request() that have been dirty for the full
    duration of the promised time.  This would require that the pager
    never map memory objects into user tasks.

4.  The mapping restriction in C above could be relaxed by having
    user tasks keep track of what memory object pages get dirty and
    when, and send a message to the pager in time to allow the pager
    to clean the pages.

5.  The pager can force the MK to tell it when pages become dirty
    using the current EMMI.  The pager response to a
    memory_object_data_request()

6.  The mapping restriction in C could be relaxed by having user
    tasks keep track of what memory object pages get dirty and when,
    and send a message to the pager in time to allow the pager to
    clean the pages.

7.  The pager can force the MK to tell it when pages become dirty
    using the current EMMI.  The pager response to a
    memory_object_data_request() would include:
        if (desired_access != VM_PROT_WRITE) { /* MK needs write
    access */
           supply page with lock_value = VM_PROT_NONE; /* grant full
    access   */
             mark page as dirty; /* pager knows page is getting dirty
    */
          }
          else /* MK does not need write access */
           /* make MK ask before writing */
           supply page with lock_value = VM_PROT_WRITE;
     The pager response to a memory_object_data_unlock() would
    include:
        if (desired_access == VM_PROT_WRITE) {
           supply page with lock_value = VM_PROT_NONE; /* grant full
    access */

           mark page as dirty; /* pager knows page is getting dirty
    */
        }
     The pager response to a memory_object_data_return() would
    include:
        mark page as clean;
     This approach requires many messages.

8.  Using vm_msync as...