Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1673503 > unrolled thread

Re: Sleeping BUG in khugepaged for i586

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Sleeping BUG in khugepaged for i586 Michal Hocko <mhocko@kernel.org> - 2017-06-23 14:10 +0200
    Re: Sleeping BUG in khugepaged for i586 Vlastimil Babka <vbabka@suse.cz> - 2017-06-23 15:20 +0200
      Re: Sleeping BUG in khugepaged for i586 Michal Hocko <mhocko@kernel.org> - 2017-06-23 15:30 +0200
        Re: Sleeping BUG in khugepaged for i586 Larry Finger <Larry.Finger@lwfinger.net> - 2017-06-23 17:30 +0200

#1673503 — Re: Sleeping BUG in khugepaged for i586

On Thu 08-06-17 16:48:31, Michal Hocko wrote:
> On Wed 07-06-17 13:56:01, David Rientjes wrote:
> > On Wed, 7 Jun 2017, Vlastimil Babka wrote:
> > 
> > > >> 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.

The code still seems to be in the mmotm tree. Are there any plans to fix
this or drop the patch?
-- 
Michal Hocko
SUSE Labs

[toc] | [next] | [standalone]

#1673551

On 06/23/2017 02:08 PM, Michal Hocko wrote:
> On Thu 08-06-17 16:48:31, Michal Hocko wrote:
>> On Wed 07-06-17 13:56:01, David Rientjes wrote:
>>
>> I suspect, so cond_resched seems indeed inappropriate on 32b systems.
> 
> The code still seems to be in the mmotm tree.

Even mainline at this point - 338a16ba1549

> Are there any plans to fix
> this or drop the patch?

https://lkml.kernel.org/r/alpine.DEB.2.10.1706191341550.97821@chino.kir.corp.google.com

[toc] | [prev] | [next] | [standalone]

#1673553

On Fri 23-06-17 15:13:45, Vlastimil Babka wrote:
> On 06/23/2017 02:08 PM, Michal Hocko wrote:
> > On Thu 08-06-17 16:48:31, Michal Hocko wrote:
> >> On Wed 07-06-17 13:56:01, David Rientjes wrote:
> >>
> >> I suspect, so cond_resched seems indeed inappropriate on 32b systems.
> > 
> > The code still seems to be in the mmotm tree.
> 
> Even mainline at this point - 338a16ba1549
> 
> > Are there any plans to fix
> > this or drop the patch?
> 
> https://lkml.kernel.org/r/alpine.DEB.2.10.1706191341550.97821@chino.kir.corp.google.com

Ahh, I have missed that. Thanks!

-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1673633

On 06/23/2017 08:25 AM, Michal Hocko wrote:
> On Fri 23-06-17 15:13:45, Vlastimil Babka wrote:
>> On 06/23/2017 02:08 PM, Michal Hocko wrote:
>>> On Thu 08-06-17 16:48:31, Michal Hocko wrote:
>>>> On Wed 07-06-17 13:56:01, David Rientjes wrote:
>>>>
>>>> I suspect, so cond_resched seems indeed inappropriate on 32b systems.
>>>
>>> The code still seems to be in the mmotm tree.
>>
>> Even mainline at this point - 338a16ba1549
>>
>>> Are there any plans to fix
>>> this or drop the patch?
>>
>> https://lkml.kernel.org/r/alpine.DEB.2.10.1706191341550.97821@chino.kir.corp.google.com
> 
> Ahh, I have missed that. Thanks!

I also missed that patch. Applying it to my box fixes the scheduling while 
atomic splats and no downside has been detected.

You may add "Reported-and-tested-by: Larry Finger <Larry.Finger@lwfinger.net>".

Thanks for everyone's efforts in fixing this problem.

Larry

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web