Mike, we're going to need a lot more detail to reproduce this.
Let me describe how I didn't reproduce it and perhaps
you can point out any differences:
- Kernel 2.4.6+ext3-2.4-0.9.1.
- Two 4gig IDE partitions on separate disks combined into a
RADI1 device.
- 64 megs of memory (32meg lowmem, 32meg highmem)
- 1 gig swapfile on the ext3 raid device.
- Ran ./tiobench.pl --threads 16
That's a *lot* more aggressive than your setup, yet
it ran to completion quite happily.
I'd be particularly interested in knowing how much memory
you're using. It certainly sounds like you're experiencing
memory exhaustion. ext3's ability to recover from out-of-memory
situations was weakened recently so as to reduce our impact
on core kernel code. I'll be generating an incremental patch
which puts that code back in.
In the meantime, could you please retest with this somewhat lame
alternative?
--- linux-2.4.6/mm/vmscan.c Wed Jul 4 18:21:32 2001
+++ lk-ext3/mm/vmscan.c Wed Jul 11 14:03:10 2001
@@ -852,6 +870,9 @@ static int do_try_to_free_pages(unsigned
* list, so this is a relatively cheap operation.
*/
if (free_shortage()) {
+ extern void shrink_journal_memory(void);
+
+ shrink_journal_memory();
ret += page_launder(gfp_mask, user);
shrink_dcache_memory(DEF_PRIORITY, gfp_mask);
shrink_icache_memory(DEF_PRIORITY, gfp_mask);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/