Browse Prior Art Database

Method of Extending OS/2's Memory Management to Recognize "User Focus"

IP.com Disclosure Number: IPCOM000108641D
Original Publication Date: 1992-Jun-01
Included in the Prior Art Database: 2005-Mar-22
Document File: 3 page(s) / 109K

Publishing Venue

IBM

Related People

Ruspino, DP: AUTHOR [+3]

Abstract

Disclosed is a method of extending the "User Focus" paradigm of the OS/2* CPU scheduler into the OS/2 Physical Memory Manager. This enhances the probability that critical segments will be in memory when they are needed.

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

Method of Extending OS/2's Memory Management to Recognize "User Focus"

       Disclosed is a method of extending the "User Focus"
paradigm of the OS/2* CPU scheduler into the OS/2 Physical Memory
Manager.  This enhances the probability that critical segments will
be in memory when they are needed.

      The thread dispatcher of OS/2 embodies the concept of multiple
priorities for threads.  There are four classes (to be called "CPU
Priority") that are germane to this problem:
      1. Time Critical (highest priority);
      2. Foreground (user's focus application);
      3. Background (applications not having the user's focus);
      4. Idle (lowest priority).

      Threads change priority between Foreground and Background based
on the user's changing attention focus. That is, the threads
associated with the task the user has on the screen and has the
user's attention are given Foreground focus priority by the
dispatching algorithm. Communication Manager, part of OS/2 Extended
Edition, has several threads at a Time Critical priority which do not
execute very often, but, when requested, need to be able to execute
within a required maximum delay. This delay is small enough that it
implies that all those segments be resident in memory at the time the
function is requested.

      Memory allocation is performed while running on the application
thread; therefore, the CPU priority controls the order that
allocations are done. However, the order that memory is purged from
the system (by either swapping the memory to disk or discarding it)
is done based strictly on "Least Recently Used" (LRU).  As a result,
low priority programs can cause memory which is a part of a higher
priority thread to be purged.
Control Block Changes
      1.   Use the "free segment forward and backward link"
double-words in the Arena header to contain a stack indicating the
priorities of threads which have used the segment.  (The "free
segment forward and backward link" fields are not used in an
allocated segment, so there is no conflict.) (CURRENT_HIGHEST,
PREVIOUS_HIGHEST[3])
      2.   Add a word to the Scheduler's table to indicate the
highest priority thread which has been dispatched since the last
execution of LRU_SWEEP. (SCHED_HIGHEST)
      3.   Add a word to each entry in the Swapper's sort table for
the segment's current priority. (CURRENT...