On Mon, Feb 22, 2010 at 08:02:58PM +0200, Avi Kivity wrote: > On 02/22/2010 08:00 PM, Andrea Arcangeli wrote: >> On Mon, Feb 22, 2010 at 12:53:11PM -0500, Rik van Riel wrote: >> >>> Once Mel's defragmentation code is in, we can kick off >>> that code instead when a hugepage allocation fails. >>> >> That will be cool yes!! Then maybe we can turn on defrag by >> default... (maybe because it'd still slowdown the allocation time) >> >> I think at least for khugepaged invoking memory compaction code by >> default is going to be good idea. And then I wonder if it makes sense >> to allow the user to disable defrag in khugepaged, if yes then it'd >> require a new sysfs file in the khugepaged directory. >> > > If we detect hugepage pressure, we can run compaction in a separate > thread, so we can have low latency allocations. > It'd require something like "kcompactd" and a definition of hugepage pressure but yeah, it's feasible. I think it should be on the relatively long-finger until such point as there is clear data on how long processes stall on compaction that could be resolved with a separate thread. I suspect what will happen in practice is that there will be pairings of (compaction,reclaim) during promotion where reclaim is periodically required to dump unused page cache before compaction can progress. If that prediction is accurate, would not help because it would be kicked awake, see that enough memory is not free and then go to sleep. kswapd could take on a dual role where it decides whether to reclaim or compact but it's harder to predict what the performance impact would be. I'm not against the idea, but I wouldn't rush to implement it sooner than it's needed either. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- 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/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>