On Thu, 23 Jul 2015, Spencer Baugh wrote: > From: Joern Engel <joern@xxxxxxxxx> > > ~150ms scheduler latency for both observed in the wild. > > Signed-off-by: Joern Engel <joern@xxxxxxxxx> > Signed-off-by: Spencer Baugh <sbaugh@xxxxxxxxxx> > --- > mm/hugetlb.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index a8c3087..2eb6919 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -1836,6 +1836,7 @@ static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count, > ret = alloc_fresh_gigantic_page(h, nodes_allowed); > else > ret = alloc_fresh_huge_page(h, nodes_allowed); > + cond_resched(); > spin_lock(&hugetlb_lock); > if (!ret) > goto out; This is wrong, you'd want to do any cond_resched() before the page allocation to avoid racing with an update to h->nr_huge_pages or h->surplus_huge_pages while hugetlb_lock was dropped that would result in the page having been uselessly allocated. > @@ -3521,6 +3522,7 @@ long follow_hugetlb_page(struct mm_struct *mm, struct vm_area_struct *vma, > spin_unlock(ptl); > ret = hugetlb_fault(mm, vma, vaddr, > (flags & FOLL_WRITE) ? FAULT_FLAG_WRITE : 0); > + cond_resched(); > if (!(ret & VM_FAULT_ERROR)) > continue; > This is almost certainly the wrong placement as well since it's inserted inside a conditional inside a while loop and there's no reason to hugetlb_fault(), schedule, and then check the return value. You need to insert your cond_resched()'s in legitimate places. -- 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>