I was glad to see the new code providing a tunable limit for buffer allocations,
but think it would be better to limit only the first round of allocations. The
reasoning is that since refill_freelist is not allowed to fail, limiting the
allocations when it can't find enough freeable buffers in the LRU lists may
force an atomic allocation, which we definitely want to avoid.
Since the BUFFER_MEM value includes both buffers and page cache, it's quite
possible that the memory limit will be reached with mostly page cache. In this
situation there may not be any suitable buffers to wait on, and then an atomic
allocation would be required. (I recently observed a machine with 500M of RAM,
heavily swapping, but with only 360 buffers, so this situation can occur.)
The attached patch removes the memory limit test following the LRU search.
Regards,
Bill
--------------D14B094A0E0DC9118CAA6B9D
Content-Type: text/plain; charset=us-ascii; name="buffer_mem90-patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="buffer_mem90-patch"
--- fs/buffer.c.old Sun Mar 22 11:30:35 1998
+++ fs/buffer.c Tue Mar 24 14:34:14 1998
@@ -817,7 +817,6 @@
*/
while (obtained < (needed >> 1) &&
nr_free_pages > freepages.min + 5 &&
- BUFFER_MEM < (buffer_mem.max_percent * num_physpages / 100) &&
grow_buffers(GFP_BUFFER, size))
obtained += PAGE_SIZE;
--------------D14B094A0E0DC9118CAA6B9D--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu