On Tue, 8 Aug 2000, octave klaba wrote:
> Hi,
> I have beed tested 2.2.17pre15 for 24h. I think the memory
> management is quite better since the memory "used" was growing
> slowly: on 2.2.16 in 5 minutes all is "used".
<snip>
> Code; c011a5d2 <update_vm_cache_conditional+8a/158> <=====
Taking a further look at your oops, I've found out that your system really
oopsed at __find_page(), and that the page passed to this function had a
invalid list pointer (->next_hash).
The only problem I found which _could_ cause that is because we did not
locked the page before starting IO on sync_page_buffers().
Here goes the patch to fix this:
--- linux.orig/fs/buffer.c Tue Aug 8 22:05:53 2000
+++ linux/fs/buffer.c Tue Aug 8 21:25:49 2000
@@ -1533,8 +1533,12 @@
busy:
too_many = (nr_buffers * bdf_prm.b_un.nfract/100);
+ set_bit(PG_locked, &page_map->flags);
+
if (!sync_page_buffers(bh, wait)) {
+ clear_bit(PG_locked, &page_map->flags);
+
/* If a high percentage of the buffers are dirty,
* wake kflushd
*/
@@ -1547,6 +1551,8 @@
*/
goto succeed;
}
+
+ clear_bit(PG_locked, &page_map->flags);
if(nr_buffers_type[BUF_DIRTY] > too_many)
wakeup_bdflush(0);
Andrea: comments?
-
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/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:16 EST