On Mon, Nov 18, 2013 at 12:48:54PM -0800, Dave Hansen wrote: > On 11/18/2013 12:20 PM, Naoya Horiguchi wrote: > >> > Really, though, a lot of things seem to have MAX_ORDER set up so that > >> > it's at 256MB or 512MB. That's an awful lot to do between rescheds. > > Yes. > > > > BTW, I found that we have the same problem for other functions like > > copy_user_gigantic_page, copy_user_huge_page, and maybe clear_gigantic_page. > > So we had better handle them too. > > Is there a problem you're trying to solve here? The common case of the > cond_resched() call boils down to a read of a percpu variable which will > surely be in the L1 cache after the first run around the loop. In other > words, it's about as cheap of an operation as we're going to get. Yes, cond_resched() is cheap if should_resched() is false (and it is in common case). > Why bother trying to "optimize" it? I thought that if we call cond_resched() too often, the copying thread can take too long in a heavy load system, because the copying thread always yields the CPU in every loop. But it seems to be an extreme case, so I can't push it strongly. Thanks, Naoya -- 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>