On 07/31/2013 10:56 PM, Minchan Kim wrote:
Yes, it's not really slow path because it could return to normal status without calling significant slow functions by reset batchcount of prepare_slowpath. I think it's tradeoff and I am biased your approach although we would lose a little performance because fair aging would recover the loss by fastpath's overhead. But who knows? Someone has a concern. So we should mention about such problems.
If the atomic operation in the fast path turns out to be a problem, I suspect we may be able to fix it by using per-cpu counters, and consolidating those every once in a while. However, it may be good to see whether there is a problem in the first place, before adding complexity. -- All rights reversed -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>