Write Buffer

Depends on	Memory Management Unit (MMU) • Spooling and Buffering

Computers spend a lot of time reading in and writing out data, at various levels of their organisation. Typically, read operations are more urgent because data is wanted now whereas writes can usually happen ‘in their own time’.

A write buffer is a device where write operations are queued and performed when there is nothing more urgent to do.

Example: during paging a ‘dirty’ page may be evicted and so need writing to disk, followed by the loading from disk of a replacement page. Disk operations are slow. The operating system can keep some pages ‘free’ and choose to load the new page into one of these before performing the write; this can considerably speed up the user’s application.

The demonstration from the paging article is reproduced here. (You can find instructions there.)

When there’s time we will include a write-buffer option in this too: until then you’ll have to be happy with a static diagram – sorry.

The point being the (urgent) read does not have to wait as long.

This is a slightly misleading example. In practice one wouldn’t copy a page of data first: the write buffering would be done by keeping one or more clean pages in the main store at all times – possibly by writing altered (‘dirty’) pages back in the background, when the disk would otherwise be idle. It shows the principle though.

Write buffering can be applied in various places where reads and writes compete for access. Disk access is a clear example; another is the processor’s access to memory although that is (or is not) managed by hardware. However, even in that case the operating system may need to be conscious of it: see below.

Write buffering is usually controlled on a page-by-page basis with a Boolean enable in each page table entry. (See also cacheability.)

---

Write buffering problems

Write buffering allows operations to complete out-of-order – i.e. in a different order from that specified by the programmer. An issue with write buffering is if a read operation wants to read back write-buffered data. It is essential to spot this case and forward the (yet unwritten) data to the read to prevent it from reading out-of-date information.

Note: a write buffer may contain more than one item; all need checking.

With forwarding it is possible to write-buffer ‘simple’ storage safely. However another issue arises with I/O devices where it may not be obvious that a dependency is present. In such cases some ordering may need to be enforced. Typically it is possible to mark whether write buffering can be performed as an attribute in the page tables; memory pages may be buffered but pages containing memory-mapped I/O may not be.

Another means of enforcing ordering, relevant when writing device drivers is the memory barrier.

---

Also refer to:	Operating System Concepts, 10th Edition: Chapter 12.4.2, pages 509-510

Context Dependencies Dependants

Max. number:

Max. distance:

Next

Articles on IO

Cacheability • Device Drivers • Direct Memory Access (DMA) • IO • Interprocess Communication • Interrupt Controller • Interrupt Service Routines (ISRs) • Interrupts • Libraries • Peripheral devices • Pipes • Queues • Queues Extra • Resources • Shell • Sockets • Spooling and Buffering • Starvation • Streams • System Calls • Thrashing • Timers • Using Peripherals • Virtualisation • Write Buffer

Articles on Memory

About this resource • Arrays • Cache • Caching • Direct Memory Access (DMA) • Dirty Bit • Dynamic Memory Allocation • Memory • Memory Barrier • Memory Fault • Memory Leak • Memory Management • Memory Management Unit (MMU) • Memory Mapped Files • Memory Mapping • Memory Mapping Example • Memory Mapping Extra • Memory Pages • Memory Protection • Memory Segmentation • Memory Sizes • Monitoring page behaviour • Page Eviction • Paging • Paging States • Pointer Arithmetic • Pointers • Relocatable Code • Resources • Shared Memory • Structures • Translation Look-aside Buffer (TLB) • Virtual Memory • Write Buffer