On Tue, Aug 17, 2010 at 10:59:18AM +0100, Mel Gorman wrote: > On Tue, Aug 17, 2010 at 11:21:15AM +0900, Minchan Kim wrote: > > Now allocation path decrease NR_FREE_PAGES _after_ it remove pages from buddy. > > It can make that actually we don't have enough pages in buddy but > > pretend to have enough pages. > > It could make same situation with free path which is your concern. > > So I think it can confuse watermark check in extreme case. > > > > So don't we need to consider _allocation_ path with conservative? > > > > I considered it and it would be desirable. The downside was that the > paths became more complicated. Take rmqueue_bulk() for example. It could > start by modifying the counters but there then needs to be a recovery > path if all the requested pages were not allocated. > > It'd be nice to see if these patches on their own were enough to > alleviate the worst of the per-cpu-counter drift before adding new > branches to the allocation path. > > Does that make sense? No problem. It was a usecase of big machine. I also hope we don't add unnecessary overhead in normal machine due to unlikely problem. Let's consider it by further step if it isn't enough. Thanks, Mel. > > -- > Mel Gorman > Part-time Phd Student Linux Technology Center > University of Limerick IBM Dublin Software Lab -- Kind regards, Minchan Kim -- 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>