On Wed, Mar 30, 2011 at 06:49:06PM +0200, Andrea Arcangeli wrote: > Hi Mel, > > On Wed, Mar 30, 2011 at 05:17:16PM +0100, Mel Gorman wrote: > > Andy Whitcroft also posted patches ages ago that were related to lumpy reclaim > > which would capture high-order pages being reclaimed for the exclusive use > > of the reclaimer. It was never shown to be necessary though. I'll read this > > thread in a bit because I'm curious to see why it came up now. > > Ok ;). > > About lumpy I wouldn't spend too much on lumpy, I hadn't intended to but the context of the capture patches was lumpy so it'd be the starting point for anyone looking at the old patches. If someone wanted to go in that direction, it would need to be adapted for compaction, reclaim/compaction and reclaim. > I'd rather spend on > other issues like the one you mentioned on lru ordering, and > compaction (compaction in kswapd has still an unknown solution, my > last attempt failed and we backed off to no compaction in kswapd which > is safe but doesn't help for GFP_ATOMIC order > 0). > Agreed. It may also be worth a quick discussion on *how* people are currently evauating their reclaim-related changes be it via tracepoints, systemtap, a patched kernel or indirect measures such as faults. > Lumpy should go away in a few releases IIRC. > > > I think we should be very wary of conflating OOM latency, reclaim latency and > > allocation latency as they are very different things with different causes. > > I think it's better to stick to successful allocation latencies only > here, or at most -ENOMEM from order > 0 which normally never happens > with compaction (not the time it takes before declaring OOM and > triggering the oom killer). > Sounds reasonable. I could discuss briefly the scripts I use based on ftrace that dump out highorder allocation latencies as it might be useful to others if this is the area they are looking at. > > I'd prefer to see OOM-related issues treated as a separate-but-related > > problem if possible so; > > > > 1. LRU ordering - are we aging pages properly or recycling through the > > list too aggressively? The high_wmark*8 change made recently was > > partially about list rotations and the associated cost so it might > > be worth listing out whatever issues people are currently aware of. > > 2. LRU ordering - dirty pages at the end of the LRU. Are we still going > > the right direction on this or is it still a shambles? > > 3. Compaction latency, other issues (IRQ disabling latency was the last > > one I'm aware of) > > 4. OOM killing and OOM latency - Whole load of churn going on in there. > > I prefer it too. The OOM killing is already covered in OOM topic from > Hugh, and we can add "OOM detection latency" to it. > Also sounds good to me. -- Mel Gorman SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>