lkml.org 
[lkml]   [1999]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
Subject[patch] flushpage and buffercache size
The current (2.3.12) flushpage done over a whole page (to release all the
bh headers) is doing:

if (!offset) {
if (!try_to_free_buffers(page))
atomic_add(PAGE_CACHE_SIZE, &buffermem);
}

But IMO the try_to_free_buffers() should never fail (well except in
the ramdisk case that seems to be not addressed yet). The buffer is
trashed, it's been completly invalidated and there's no reason for left it
in memory. Nobody can start I/O in the meantime since we hold the
page-lock and we carefully waited for all previous in progress I/O to
complete before try to free the buffers. So it seems to me that if
try_to_free_buffers fails we have some problem somewhere (maybe I
overlooked something...).

--- 2.3.12/fs/buffer.c Sun Aug 1 18:11:17 1999
+++ 2.3.12-lru/fs/buffer.c Tue Aug 3 21:39:44 1999
@@ -1287,13 +1287,12 @@
* cached value unconditionally, so real IO is not
* possible anymore.
*
- * If the free doesn't work out, the buffers can be
- * left around - they just turn into anonymous buffers
- * instead.
+ * The free must work since the buffer is been trashed and there's
+ * no one good reason for left it in memory.
*/
if (!offset) {
if (!try_to_free_buffers(page))
- atomic_add(PAGE_CACHE_SIZE, &buffermem);
+ BUG();
}

return 0;
Andrea


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.043 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site