On Thu, Feb 03, 2011 at 01:15:49PM +0000, Mel Gorman wrote: > I got a chance to test this today and I see similar results. I still do see > kswapd entering D state occasionally and I'm convinced it's because it's > calling congestion_wait() i.e. it's not real IO but it's being accounted > for as an IO-related wait. That said, it's mostly asleep (S) or running (R) > and free memory is at reasonable levels so it's a big improvement. I never seen it in D state here but maybe it happens occasionally and I would expect the R/S/D states not to be altered by this change, just the free levels should be altered. > I think this is the best direction to take for the moment to close the obvious > bug. More thought is required on when exactly kswapd is going to sleep and > on what zones the allocator should be using but there is no quick answer that > will simply have other consequences. As much as I'd like to investigate this > further now, I'm in the process of changing jobs and expect to be heavily > disrupted for at least a month during the changeover. So, for this; I full agree we should check (with less hurry) exactly when kswapd is going to sleep in this load in case it's waken too early. I expect it will remain an independent issue and I don't expect this patch having to be reversed once we figure why free levels stays always at "high" and we don't see them reaching "low". Thanks for the review, Andrea -- 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>