Messages in this thread Patch in this message | | | Date | Tue, 3 Aug 1999 21:42:22 +0200 (CEST) | From | Andrea Arcangeli <> | 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/
| |