On Fri, Apr 15, 2011 at 12:52:47PM -0600, Tim Gardner wrote: > Mel, > > Please find attached a backport for > 88f5acf88ae6a9778f6d25d0d5d7ec2d57764a97 that Greg requested for > 2.6.32.y stable. There are some fairly substantial differences in > the 2.6.38 mm/vmscan.c and the 2.6.32 backport that I'd like to have > reviewed. That being said, I don't actually have a reproducer for > 2.6.32 that causes the same issues as are observed on 2.6.35. To > test I'm booting with "maxcpus=0 mem=128M" and running the command >
Reproducing this requires many CPUs so I'd be surprised if you saw the problem with this configuration. > dd if=/dev/zero of=/dev/sdb count=1 bs=1028653056 > > where /dev/sdb is a slow USB flash drive. This is also a single-threaded test so again I'd be surprised if you saw the problem. The original bug report used multiple dd instances on multiple sparse files. I don't think the speed of the backing storage was a big factor because it wasn't mentioned but maybe it is important. I never saw the same performance problems as reported by Shaohua Li. I was using oprofile and reducing the time spent in watermark-related functions without seeing the same level of performance loss. > And yes, it dives deep > into swap space while building the output buffer. 2.6.32 behaves > quite well with or without this patch, so perhaps we ought to leave > well enough alone. If it ain't broke, don't fix it ? > > 2.6.35.12 plus this patch (which has been accepted by Andi Kleen) is > a different story. The same boot command (though using nr_cpus=0) > causes an oops fairly quickly, and has wrecked the rootfs 3 times > now. I'm still working on getting a good trace. > Oops's are new. This patch was only meant to fix a performance regression not a functional one so if oops's are now in evidence, it's a problem with the backport. I do note that more than one thing is being backported here. Specifically, it looks like it is also backporting [f50de2d: vmscan: have kswapd sleep for a short interval and double check it should be asleep] but it is not commented on why it was necessary. If it's the calling to sleeping_prematurely() that is bothering you, ignore those portions. You have the other call sites to zone_watermark_ok_safe. Maybe you were worried about when to call restore_pgdat_percpu_threshold() and reduce_pgdat_percpu_threshold()? If this is the case, the correct place is around where kswapd() calls schedule() without worrying about the sleeping_prematurely stuff. > From be9cf15b4ae14032bea2fef33c81dddf8a4fd9e0 Mon Sep 17 00:00:00 2001 > From: Mel Gorman <[email protected]> > Date: Thu, 13 Jan 2011 15:45:41 -0800 > Subject: [PATCH] mm: page allocator: adjust the per-cpu counter threshold > when memory is low > > backported from 88f5acf88ae6a9778f6d25d0d5d7ec2d57764a97 > > <SNIP> -- Mel Gorman SUSE Labs _______________________________________________ stable mailing list [email protected] http://linux.kernel.org/mailman/listinfo/stable
