refill_freelist Fix for 2.1.50

• Patch Index 2.1 Unofficial Patches
  
• Previous Patch: penguin logo patch for kernel 2.1.64
  
• Next Patch: WriteThrough pageclearing, 2.1.50, anyone with a PPro?
  

With the ongoing discussion of 2.0.31 buffers, this seems like a good time to post one further refinement to 2.1.50 refill_freelist. This corrects the main remaining deficiency by preventing a short-term buffer shortage from depleting the system's reserved pages.

The problem with the current implementation is that it doesn't wait for locked buffers to unlock before resorting to atomic allocation to create new buffers. If the system has many locked (or dirty) buffers and suddenly needs more buffers, the reserved pages can be quickly depleted, when all that was needed was to write out the dirty buffers and wait for them to unlock. (The call to wakeup_bdflush(1) doesn't mean "wait for them to unlock", it just means "wait for them to be written out".)

This patch corrects this with the following changes:

1. If the attempts to free or allocate buffers without using reserved pages have failed (free list still empty), check whether any buffers are dirty, and wake bdflush before attempting to use reserved pages.

2. After waking bdflush, any dirty buffers will have become locked. Before using reserved pages, find an unused locked buffer and wait for it to unlock. After it unlocks, loop back to harvest it.

3. If for some reason we still can't get a buffer, use just one reserved page and then return.

4. Finally (and most unlikely), do a schedule() and keep trying.

I've been testing this since 2.1.47 by doing multiple make -j3 compiles in 6M, and rarely have to use even one reserved page. By protecting the reserved pages, we can ensure that other parts of the system don't become unstable because of low memory.