vmscan: simplify shrink_inactive_list()
in [Kernel]
|
Prev: gpio: max732x: fix input configuration for open-drain pins
Next: [PATCH v2 3/5] KVM MMU: cleanup for restart hlist walking
From: Dave Chinner on 15 Apr 2010 19:50 On Thu, Apr 15, 2010 at 06:54:16PM +0200, Andi Kleen wrote: > > It's a buying-time venture, I'll agree but as both approaches are only > > about reducing stack stack they wouldn't be long-term solutions by your > > criteria. What do you suggest? > > (from easy to more complicated): > > - Disable direct reclaim with 4K stacks Just to re-iterate: we're blowing the stack with direct reclaim on x86_64 w/ 8k stacks. The old i386/4k stack problem is a red herring. Cheers, Dave. -- Dave Chinner david(a)fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on 16 Apr 2010 03:20 On Fri, Apr 16, 2010 at 09:40:13AM +1000, Dave Chinner wrote: > On Thu, Apr 15, 2010 at 06:54:16PM +0200, Andi Kleen wrote: > > > It's a buying-time venture, I'll agree but as both approaches are only > > > about reducing stack stack they wouldn't be long-term solutions by your > > > criteria. What do you suggest? > > > > (from easy to more complicated): > > > > - Disable direct reclaim with 4K stacks > > Just to re-iterate: we're blowing the stack with direct reclaim on > x86_64 w/ 8k stacks. The old i386/4k stack problem is a red > herring. Yes that's known, but on 4K it will definitely not work at all. -Andi -- ak(a)linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mel Gorman on 16 Apr 2010 05:50 On Thu, Apr 15, 2010 at 02:22:01PM -0400, Valdis.Kletnieks(a)vt.edu wrote: > On Thu, 15 Apr 2010 14:15:33 BST, Mel Gorman said: > > > Yep. I modified bloat-o-meter to work with stacks (imaginatively calling it > > stack-o-meter) and got the following. The prereq patches are from > > earlier in the thread with the subjects > > Think that's a script worth having in-tree? Ahh, it's a hatchet-job at the moment. I copied bloat-o-meter and altered one function. I made a TODO note to extend bloat-o-meter properly and that would be worth merging. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mel Gorman on 16 Apr 2010 11:00 On Thu, Apr 15, 2010 at 06:54:16PM +0200, Andi Kleen wrote: > > It's a buying-time venture, I'll agree but as both approaches are only > > about reducing stack stack they wouldn't be long-term solutions by your > > criteria. What do you suggest? > > (from easy to more complicated): > > - Disable direct reclaim with 4K stacks Do not like. While I can see why 4K stacks are a serious problem, I'd sooner see 4K stacks disabled than have the kernel behave so differently for direct reclaim. It's be tricky to spot regressions in reclaim that were due to this .config option > - Do direct reclaim only on separate stacks This is looking more and more attractive. > - Add interrupt stacks to any 8K stack architectures. This is a similar but separate problem. It's similar in that interrupt stacks can splice subsystems together in terms of stack usage. > - Get rid of 4K stacks completely Why would we *not* do this? I can't remember the original reasoning behind 4K stacks but am guessing it helped fork-orientated workloads in startup times in the days before lumpy reclaim and better fragmentation control. Who typically enables this option? > - Think about any other stackings that could give large scale recursion > and find ways to run them on separate stacks too. The patch series I threw up about reducing stack was a cut-down approach. Instead of using separate stacks, keep the stack usage out of the main caller path where possible. > - Long term: maybe we need 16K stacks at some point, depending on how > good the VM gets. Alternative would be to stop making Linux more complicated, > but that's unlikely to happen. > Make this Plan D if nothing else works out and we still hit a wall? -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Johannes Weiner on 16 Apr 2010 19:00
On Thu, Apr 15, 2010 at 06:21:36PM +0100, Mel Gorman wrote: > From: KOSAKI Motohiro <kosaki.motohiro(a)jp.fujitsu.com> > > Now, max_scan of shrink_inactive_list() is always passed less than > SWAP_CLUSTER_MAX. then, we can remove scanning pages loop in it. > This patch also help stack diet. > > detail > - remove "while (nr_scanned < max_scan)" loop > - remove nr_freed (now, we use nr_reclaimed directly) > - remove nr_scan (now, we use nr_scanned directly) > - rename max_scan to nr_to_scan > - pass nr_to_scan into isolate_pages() directly instead > using SWAP_CLUSTER_MAX > > Signed-off-by: KOSAKI Motohiro <kosaki.motohiro(a)jp.fujitsu.com> Reviewed-by: Johannes Weiner <hannes(a)cmpxchg.org> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |