lkml.org 
[lkml]   [1998]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
Subjectminor patch for 2.1.90 fs/buffer.c
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--- 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;
\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.022 / U:1.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site