On Wed 07-06-17 13:56:01, David Rientjes wrote:

On Wed, 7 Jun 2017, Vlastimil Babka wrote:

quoted

quoted

quoted

Hmm I'd expect such spin lock to be reported together with mmap_sem in
the debugging "locks held" message?

My bisection of the problem is about half done. My latest good version is commit 
7b8cd33 and the latest bad one is 2ea659a. Only about 7 steps to go.

Hmm, your bisection will most likely just find commit 338a16ba15495
which added the cond_resched() at mm/khugepaged.c:655. CCing David who
added it.

I agree it's probably going to bisect to 338a16ba15495 since it's the 
cond_resched() at the line number reported, but I think there must be 
something else going on.  I think the list of locks held by khugepaged is 
correct because it matches with the implementation.  The preempt_count(), 
as suggested by Andrew, does not.  If this is reproducible, I'd like to 
know what preempt_count() is.

collapse_huge_page
  pte_offset_map
    kmap_atomic
      kmap_atomic_prot
        preempt_disable
  __collapse_huge_page_copy
  pte_unmap
    kunmap_atomic
      __kunmap_atomic
        preempt_enable

I suspect, so cond_resched seems indeed inappropriate on 32b systems.

-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>