Minirel_1 - EECS 484, Winter 2011 Minirel 2K, Part 1:...

Info iconThis preview shows pages 1–2. Sign up to view the full content.

View Full Document Right Arrow Icon
Minirel2K Part 1: The Buffer Manager Page 1 of 8 EECS 484, Winter 2011 Minirel 2K, Part 1: Buffer Manager Due: March 23 rd at 10:30AM Introduction The first part of the Minirel2K project involves implementing a buffer manager. Recall that a database buffer pool is a collection of memory frames that are used to hold database pages that have been read from disk into memory. Since the database itself may be many times larger than the size of memory, only a subset of the database pages can fit in memory at any given time. The buffer manager is used to control which pages are in memory at any particular time. Whenever a request is made (by higher layers of the DBMS) for a data page, the buffer manager must check to see whether the page is already in the buffer pool. If so, the buffer manager simply returns a pointer to the page. If not, the buffer manager frees a frame, and then reads the requested page into the free frame. Buffer Replacement Policy – “Love Hints” There are many ways of deciding which page to replace when a free frame is needed. Common policies include LRU, MRU, and FIFO. However, as we saw in class, blindly applying one of these policies may lead to undesirable behavior (e.g., sequential flooding for LRU) since the buffer manager is unaware of the activities of higher layers of the DBMS. One way to address this problem is for the upper layers of the DBMS to send hints to the buffer manager about what they are doing. For the purposes of this project, we will consider a very simple kind of hint called a love hint . When a caller unpins a page, the caller can send a love hint to the buffer manager, which indicates that it is likely to request the page again soon. In this case, the buffer manager should try, if possible, to keep the page in the buffer pool. For this project, you will implement a page replacement policy that combines love hints with the Clock page replacement algorithm. (Clock mimics LRU, but has much less overhead.) Conceptually, the buffer frames are arranged in a circular list. A frame may be empty, or it can be used to hold a page. Each frame has the following associated bookkeeping information: Valid bit – Set to true if the frame contains a database page Loved bit – Set to true if someone has recently “loved” the page Pincount – Number of callers currently using the page contained in the frame Dirty bit – Set to true if the page in the frame has been modified since it was fetched from disk Figure 1 provides an overview of the page replacement algorithm. At any point in time, the clock “hand” (an integer between 0 and NUMBUFS – 1) points to some frame in the buffer pool. Whenever a caller requests a page (via a call to bufMgr::allocBuf), the clock hand is advanced (using modular arithmetic so that it does not go past NUMBUFS – 1). Each time the clock passes a frame, the loved bit is examined and cleared. If the loved bit is true, this means that the page was “recently” loved, so it should not be replaced. However, if the loved bit is false, the
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Image of page 2
This is the end of the preview. Sign up to access the rest of the document.

Page1 / 8

Minirel_1 - EECS 484, Winter 2011 Minirel 2K, Part 1:...

This preview shows document pages 1 - 2. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online