Messages in this thread | | | Date | Mon, 18 Nov 2013 16:56:18 -0500 | From | Naoya Horiguchi <> | Subject | Re: [PATCH] mm: call cond_resched() per MAX_ORDER_NR_PAGES pages copy |
| |
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
| |