Re: [Bug 204165] New: 100% CPU usage in compact_zone_order

[howaboutsynergy@protonmail.com]

[-- Attachment #1.1: Type: text/plain, Size: 2342 bytes --]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, July 15, 2019 11:25 PM, Andrew Morton <akpm@linux-foundation.org> wrote:

> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
Roger that.

> 

> On Sat, 13 Jul 2019 19:20:21 +0000 bugzilla-daemon@bugzilla.kernel.org wrote:
> 

> > https://bugzilla.kernel.org/show_bug.cgi?id=204165
> > 

> >             Bug ID: 204165
> >            Summary: 100% CPU usage in compact_zone_order
> >     

> 

> Looks like we have a lockup in compact_zone()
> 

> >            Product: Memory Management
> >            Version: 2.5
> >     Kernel Version: 5.2.0-g0ecfebd2b524
> >           Hardware: x86-64
> >                 OS: Linux
> >               Tree: Mainline
> >             Status: NEW
> >           Severity: normal
> >           Priority: P1
> >          Component: Page Allocator
> >           Assignee: akpm@linux-foundation.org
> >           Reporter: howaboutsynergy@pm.me
> >         Regression: No
> >     

> 

> I assume this should be "yes". Did previous kernels exhibit this
> behavior or is it new in 5.2?

Regression: yes? 

I'm not sure... 

tl;dr: seen with kernel linux-stable 5.1.8.r0.g937cc0cc22a2-1
And really not sure if I've seen it before.

long read:
At least one previous kernel did because I've seen this before in https://bugzilla.kernel.org/show_bug.cgi?id=203833#c1 where I thought it was due to 'teo' governor but it wasn't (I'm using 'menu' gov. now)

I didn't mention kernel version there, but according to irc logs where I seek'd help at the time, the date was June 10th 2019 3am, checking which kernel I was running at the time (thanks to my q1q repo. git logs) it was 5.1.8 (stable)kernel to which I updated on Sun Jun 9 10:50:09 2019 +0200 and have not changed until Tue Jun 11 05:16:59 2019 +0200
local/linux-stable 5.1.8.r0.g937cc0cc22a2-1 (builtbydaddy)

Side note:
I've encountered something similar here https://github.com/constantoverride/qubes-linux-kernel/issues/2
 where kworker would randomly start using 100% CPU and couldn't be killed. The kernel there was 4.18.7, the VM had very little RAM in Qubes there. Since it's probably a different bug due to that stacktrace being so different/unrelated, please ignore.



[-- Attachment #1.2: publickey - howaboutsynergy@protonmail.com - 0x947B9B34.asc --]
[-- Type: application/pgp-keys, Size: 3227 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 855 bytes --]