On Tuesday, 19 December 2006 00:17, Andrew Morton wrote: > On Mon, 18 Dec 2006 23:38:23 +0100 > "Rafael J. Wysocki" <rjw at sisk.pl> wrote: > > > > > Looks like we have a problem with slab shrinking here. > > > > > > > > Could you please use gdb to check what exactly is at shrink_slab+0x9e? > > > > > > Sure, but not till Friday, sorry (I am away). > > > > I reproduced this on one box, but then it turned out that EIP was at line 195 > > of mm/vmscan.c where there was > > > > do_div(delta, lru_pages + 1); > > That implies that we passed it lru_pages=-1. > > Presumably the logic in > vmscanc-account-for-memory-already-freed-in-seeking-to.patch caused that. > > > Well, I have no idea how this can lead to a divide error (lru_pages is > > unsigned). > > > > I'm unable to reproduce this on another i386 box, so it seems to be somewhat > > configuration specific. > > > > There is one wart in shrink_all_memory() and I think we should fix that in > 2.6.20. > > Please check the below. Fine by me. > I'll drop vmscanc-account-for-memory-already-freed-in-seeking-to.patch. It > has other stuff in it which we might still need. But altering > sc->swap_cluster_max in that manner looks odd. Agreed. Greetings, Rafael
