Mea culpa! I see now that there's one way in which my patch, as it
stands, makes the cp-bug problem much worse. I was testing something
in "vmscan.c" that, in retrospect, was really quite stupid---it
entirely sabotaged the fast freeing of page cache pages.
If, after applying the patch, you replace the definition of
"do_try_to_free_page" in "linux/mm/vmscan.c" with the following, it
seems to fix the cp-bug, at least when I use my buffermem and
pagecache settings. (I don't expect that performance would be any
*better* than the stock kernel with the same buffermem and pagecache
settings, but I'm not sure---can you test it and see?)
Anyway, as I write this, I'm copying 50 megs of zeroes to "/dev/null".
Performance is a bit sluggish at times, but the machine is still quite
usable. And, I certainly haven't been forced to reboot.
Kevin <buhr@stat.wisc.edu>
* * *
static inline int do_try_to_free_page(int gfp_mask)
{
static int state = 0;
int i=6;
int stop;
/* We try harder if we are waiting .. */
stop = 3;
if (gfp_mask & __GFP_WAIT)
stop = 0;
if (state > 1 &&
(((buffermem >> PAGE_SHIFT) * 100 > buffer_mem.borrow_percent * num_physpages)
|| (page_cache_size * 100 > page_cache.borrow_percent * num_physpages)))
state = 0;
switch (state) {
do {
case 0:
if (shrink_mmap(i, gfp_mask))
return 1;
state = 1;
case 1:
/* shrink slab caches */
shrink_dcache_memory(i);
shrink_inode_memory(i);
/* reap unused slabs */
if (kmem_cache_reap(gfp_mask)) {
return 1;
}
state = 2;
case 2:
if ((gfp_mask & __GFP_IO) && shm_swap(i, gfp_mask))
return 1;
state = 3;
case 3:
if (swap_out(i, gfp_mask))
return 1;
state = 0;
i--;
} while ((i - stop) >= 0);
}
return 0;
}
-
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.altern.org/andrebalsa/doc/lkml-faq.html