Re: Sleeping BUG in khugepaged for i586

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

Re: Sleeping BUG in khugepaged for i586

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

Re: Sleeping BUG in khugepaged for i586

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

Re: Sleeping BUG in khugepaged for i586

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

Re: Sleeping BUG in khugepaged for i586

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

Re: Sleeping BUG in khugepaged for i586

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

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

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

Re: Sleeping BUG in khugepaged for i586

On Wed 14-06-17 18:12:06, David Rientjes wrote: > On Thu, 8 Jun 2017, Michal Hocko wrote: > > > collapse_huge_page > > pte_offset_map > > kmap_atomic > > kmap_atomic_prot > > preempt_disable > > __collapse_huge_page_copy > > pte_unmap > > kunmap_atomic > >

Re: Sleeping BUG in khugepaged for i586

On Wed 14-06-17 18:12:06, David Rientjes wrote: > On Thu, 8 Jun 2017, Michal Hocko wrote: > > > collapse_huge_page > > pte_offset_map > > kmap_atomic > > kmap_atomic_prot > > preempt_disable > > __collapse_huge_page_copy > > pte_unmap > > kunmap_atomic > >

Re: Sleeping BUG in khugepaged for i586

On Thu, 8 Jun 2017, Michal Hocko wrote: > 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

Re: Sleeping BUG in khugepaged for i586

On Thu, 8 Jun 2017, Michal Hocko wrote: > 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

Re: Sleeping BUG in khugepaged for i586

On Mon, 12 Jun 2017, Michal Hocko wrote: > > These are not soft lockups, these are need_resched warnings. We monitor > > how long need_resched has been set and when a thread takes an excessive > > amount of time to reschedule after it has been set. A loop of 512 pages > > with ptl contention

Re: Sleeping BUG in khugepaged for i586

On Mon, 12 Jun 2017, Michal Hocko wrote: > > These are not soft lockups, these are need_resched warnings. We monitor > > how long need_resched has been set and when a thread takes an excessive > > amount of time to reschedule after it has been set. A loop of 512 pages > > with ptl contention

Re: Sleeping BUG in khugepaged for i586

On Sun 11-06-17 16:28:11, David Rientjes wrote: > On Sat, 10 Jun 2017, Michal Hocko wrote: > > > > > I would just pull the cond_resched out of __collapse_huge_page_copy > > > > right after pte_unmap. But I am not really sure why this cond_resched is > > > > really needed because the changelog of

Re: Sleeping BUG in khugepaged for i586

On Sun 11-06-17 16:28:11, David Rientjes wrote: > On Sat, 10 Jun 2017, Michal Hocko wrote: > > > > > I would just pull the cond_resched out of __collapse_huge_page_copy > > > > right after pte_unmap. But I am not really sure why this cond_resched is > > > > really needed because the changelog of

Re: Sleeping BUG in khugepaged for i586

On Sat, 10 Jun 2017, Michal Hocko wrote: > > > I would just pull the cond_resched out of __collapse_huge_page_copy > > > right after pte_unmap. But I am not really sure why this cond_resched is > > > really needed because the changelog of the patch which adds is is quite > > > terse on details. >

Re: Sleeping BUG in khugepaged for i586

On Sat, 10 Jun 2017, Michal Hocko wrote: > > > I would just pull the cond_resched out of __collapse_huge_page_copy > > > right after pte_unmap. But I am not really sure why this cond_resched is > > > really needed because the changelog of the patch which adds is is quite > > > terse on details. >

Re: Sleeping BUG in khugepaged for i586

On Fri 09-06-17 15:38:44, David Rientjes wrote: > On Thu, 8 Jun 2017, Michal Hocko wrote: > > > I would just pull the cond_resched out of __collapse_huge_page_copy > > right after pte_unmap. But I am not really sure why this cond_resched is > > really needed because the changelog of the patch

Re: Sleeping BUG in khugepaged for i586

On Fri 09-06-17 15:38:44, David Rientjes wrote: > On Thu, 8 Jun 2017, Michal Hocko wrote: > > > I would just pull the cond_resched out of __collapse_huge_page_copy > > right after pte_unmap. But I am not really sure why this cond_resched is > > really needed because the changelog of the patch

Re: Sleeping BUG in khugepaged for i586

On Thu, 8 Jun 2017, Michal Hocko wrote: > I would just pull the cond_resched out of __collapse_huge_page_copy > right after pte_unmap. But I am not really sure why this cond_resched is > really needed because the changelog of the patch which adds is is quite > terse on details. I'm not sure what

Re: Sleeping BUG in khugepaged for i586

On Thu, 8 Jun 2017, Michal Hocko wrote: > I would just pull the cond_resched out of __collapse_huge_page_copy > right after pte_unmap. But I am not really sure why this cond_resched is > really needed because the changelog of the patch which adds is is quite > terse on details. I'm not sure what

Re: Sleeping BUG in khugepaged for i586

On 06/09/2017 01:48 AM, Vlastimil Babka wrote: On 06/08/2017 10:30 PM, Michal Hocko wrote: But I guess you are primary after syncing the preemptive mode for 64 and 32b systems, right? I agree that having a different model is more than unfortunate because 32b gets much less testing coverage and

Re: Sleeping BUG in khugepaged for i586

On 06/09/2017 01:48 AM, Vlastimil Babka wrote: On 06/08/2017 10:30 PM, Michal Hocko wrote: But I guess you are primary after syncing the preemptive mode for 64 and 32b systems, right? I agree that having a different model is more than unfortunate because 32b gets much less testing coverage and

Re: Sleeping BUG in khugepaged for i586

On Fri 09-06-17 08:48:58, Vlastimil Babka wrote: > On 06/08/2017 10:30 PM, Michal Hocko wrote: > > But I guess you are primary after syncing the preemptive mode for 64 and > > 32b systems, right? I agree that having a different model is more than > > unfortunate because 32b gets much less testing

Re: Sleeping BUG in khugepaged for i586

On Fri 09-06-17 08:48:58, Vlastimil Babka wrote: > On 06/08/2017 10:30 PM, Michal Hocko wrote: > > But I guess you are primary after syncing the preemptive mode for 64 and > > 32b systems, right? I agree that having a different model is more than > > unfortunate because 32b gets much less testing

Re: Sleeping BUG in khugepaged for i586

On 06/08/2017 10:30 PM, Michal Hocko wrote: > But I guess you are primary after syncing the preemptive mode for 64 and > 32b systems, right? I agree that having a different model is more than > unfortunate because 32b gets much less testing coverage and so a risk of > introducing a new bug is just

Re: Sleeping BUG in khugepaged for i586

On 06/08/2017 10:30 PM, Michal Hocko wrote: > But I guess you are primary after syncing the preemptive mode for 64 and > 32b systems, right? I agree that having a different model is more than > unfortunate because 32b gets much less testing coverage and so a risk of > introducing a new bug is just

Re: Sleeping BUG in khugepaged for i586

On Thu 08-06-17 22:18:22, Michal Hocko wrote: > On Thu 08-06-17 10:05:57, Matthew Wilcox wrote: > > On Thu, Jun 08, 2017 at 04:48:31PM +0200, Michal Hocko wrote: > > > On Wed 07-06-17 13:56:01, David Rientjes wrote: > > > > I agree it's probably going to bisect to 338a16ba15495 since it's the > >

Re: Sleeping BUG in khugepaged for i586

On Thu 08-06-17 22:18:22, Michal Hocko wrote: > On Thu 08-06-17 10:05:57, Matthew Wilcox wrote: > > On Thu, Jun 08, 2017 at 04:48:31PM +0200, Michal Hocko wrote: > > > On Wed 07-06-17 13:56:01, David Rientjes wrote: > > > > I agree it's probably going to bisect to 338a16ba15495 since it's the > >

Re: Sleeping BUG in khugepaged for i586

On Thu 08-06-17 10:05:57, Matthew Wilcox wrote: > On Thu, Jun 08, 2017 at 04:48:31PM +0200, Michal Hocko wrote: > > On Wed 07-06-17 13:56:01, David Rientjes wrote: > > > I agree it's probably going to bisect to 338a16ba15495 since it's the > > > cond_resched() at the line number reported, but I

Re: Sleeping BUG in khugepaged for i586

On Thu 08-06-17 10:05:57, Matthew Wilcox wrote: > On Thu, Jun 08, 2017 at 04:48:31PM +0200, Michal Hocko wrote: > > On Wed 07-06-17 13:56:01, David Rientjes wrote: > > > I agree it's probably going to bisect to 338a16ba15495 since it's the > > > cond_resched() at the line number reported, but I

Re: Sleeping BUG in khugepaged for i586

On Thu, Jun 08, 2017 at 04:48:31PM +0200, Michal Hocko wrote: > On Wed 07-06-17 13:56:01, David Rientjes wrote: > > 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

Re: Sleeping BUG in khugepaged for i586

On Thu, Jun 08, 2017 at 04:48:31PM +0200, Michal Hocko wrote: > On Wed 07-06-17 13:56:01, David Rientjes wrote: > > 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

Re: Sleeping BUG in khugepaged for i586

On 06/07/2017 03:56 PM, 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

Re: Sleeping BUG in khugepaged for i586

On 06/07/2017 03:56 PM, 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

Re: Sleeping BUG in khugepaged for i586

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

Re: Sleeping BUG in khugepaged for i586

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

Re: Sleeping BUG in khugepaged for i586

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

Re: Sleeping BUG in khugepaged for i586

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

Re: Sleeping BUG in khugepaged for i586

On 06/06/2017 05:01 PM, Larry Finger wrote: > On 06/06/2017 09:02 AM, Vlastimil Babka wrote: >> On 06/05/2017 11:44 PM, Andrew Morton wrote: >>> On Sat, 3 Jun 2017 14:24:26 -0500 Larry Finger >>> wrote: >>> I recently turned on locking diagnostics for a Dell

Re: Sleeping BUG in khugepaged for i586

On 06/06/2017 05:01 PM, Larry Finger wrote: > On 06/06/2017 09:02 AM, Vlastimil Babka wrote: >> On 06/05/2017 11:44 PM, Andrew Morton wrote: >>> On Sat, 3 Jun 2017 14:24:26 -0500 Larry Finger >>> wrote: >>> I recently turned on locking diagnostics for a Dell Latitude D600 laptop,

Re: Sleeping BUG in khugepaged for i586

On 06/06/2017 09:02 AM, Vlastimil Babka wrote: On 06/05/2017 11:44 PM, Andrew Morton wrote: On Sat, 3 Jun 2017 14:24:26 -0500 Larry Finger wrote: I recently turned on locking diagnostics for a Dell Latitude D600 laptop, which requires a 32-bit kernel. In the log I

Re: Sleeping BUG in khugepaged for i586

On 06/06/2017 09:02 AM, Vlastimil Babka wrote: On 06/05/2017 11:44 PM, Andrew Morton wrote: On Sat, 3 Jun 2017 14:24:26 -0500 Larry Finger wrote: I recently turned on locking diagnostics for a Dell Latitude D600 laptop, which requires a 32-bit kernel. In the log I found the following: BUG:

Re: Sleeping BUG in khugepaged for i586

On 06/05/2017 11:44 PM, Andrew Morton wrote: > On Sat, 3 Jun 2017 14:24:26 -0500 Larry Finger > wrote: > >> I recently turned on locking diagnostics for a Dell Latitude D600 laptop, >> which >> requires a 32-bit kernel. In the log I found the following: >> >> BUG:

Re: Sleeping BUG in khugepaged for i586

On 06/05/2017 11:44 PM, Andrew Morton wrote: > On Sat, 3 Jun 2017 14:24:26 -0500 Larry Finger > wrote: > >> I recently turned on locking diagnostics for a Dell Latitude D600 laptop, >> which >> requires a 32-bit kernel. In the log I found the following: >> >> BUG: sleeping function called

Re: Sleeping BUG in khugepaged for i586

On Sat, 3 Jun 2017 14:24:26 -0500 Larry Finger wrote: > I recently turned on locking diagnostics for a Dell Latitude D600 laptop, > which > requires a 32-bit kernel. In the log I found the following: > > BUG: sleeping function called from invalid context at

Re: Sleeping BUG in khugepaged for i586

On Sat, 3 Jun 2017 14:24:26 -0500 Larry Finger wrote: > I recently turned on locking diagnostics for a Dell Latitude D600 laptop, > which > requires a 32-bit kernel. In the log I found the following: > > BUG: sleeping function called from invalid context at mm/khugepaged.c:655 > in_atomic():

Sleeping BUG in khugepaged for i586

I recently turned on locking diagnostics for a Dell Latitude D600 laptop, which requires a 32-bit kernel. In the log I found the following: BUG: sleeping function called from invalid context at mm/khugepaged.c:655 in_atomic(): 1, irqs_disabled(): 0, pid: 20, name: khugepaged 1 lock held by

Sleeping BUG in khugepaged for i586

I recently turned on locking diagnostics for a Dell Latitude D600 laptop, which requires a 32-bit kernel. In the log I found the following: BUG: sleeping function called from invalid context at mm/khugepaged.c:655 in_atomic(): 1, irqs_disabled(): 0, pid: 20, name: khugepaged 1 lock held by