>Alan, list, et all,
>
I've now realised that this discussion is ongoing, and would just like to chip in with my newer results.
<znip>
>I have not determined if it is static void fast_clear_page(void *page), or static void fast_copy_page(void *to, void >*from) which is to blame here, but I will continue investigating.
>
I've determined that with the Athlon-optimized fast_copy_page, the machine is easy to push into oopsing. Just starting a dd with blocksize 128M (half available ram) provokes an oops. This is repeatable, consistent and almost fun.
With the Athlon-optimized fast_clear_page, tho, the machine seems stable. I can start the above dd, and two more like it (eating some 128MB into swap as well), and then start using the machine.
It's now been churning away like that for half an hour, and I've never had to wait that long for an oops.
How much is gained using the Athlon-optimized fast_copy_page over the normal fast_copy_page?
Yours,
-S
-- Simen Thoresen, Beowulf-cleaner and random artist - close and personal.Er det ikke rart? The gnu RART-project on http://valinor.dolphinics.no:1080/~simentt/rart
- 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/
This archive was generated by hypermail 2b29 : Fri Sep 07 2001 - 21:00:12 EST