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

Groups > linux.debian.kernel > #55717 > unrolled thread

Bug#843349: linux-image-4.7.0-1-amd64: Intermittently high system load, sluggish response, no /proc/<pid>/stat utime,stime,etc. reported

Back to article view | Back to linux.debian.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

  Bug#843349: linux-image-4.7.0-1-amd64: Intermittently high system load, sluggish response, no /proc/<pid>/stat utime,stime,etc. reported Ben Hutchings <ben@decadent.org.uk> - 2016-11-13 05:30 +0100
    Bug#843349: linux-image-4.7.0-1-amd64: Intermittently high system load, sluggish response, no /proc/<pid>/stat utime,stime,etc. reported Tom Lee <debian@tomlee.co> - 2016-11-20 23:20 +0100
      Bug#843349: linux-image-4.7.0-1-amd64: Intermittently high system load, sluggish response, no /proc/<pid>/stat utime,stime,etc. reported Tom Lee <debian@tomlee.co> - 2016-11-20 23:30 +0100
        Bug#843349: linux-image-4.7.0-1-amd64: Intermittently high system load, sluggish response, no /proc/<pid>/stat utime,stime,etc. reported Tom Lee <debian@tomlee.co> - 2017-01-26 03:00 +0100
          Bug#843349: linux-image-4.7.0-1-amd64: Intermittently high system load, sluggish response, no /proc/<pid>/stat utime,stime,etc. reported Ben Hutchings <ben@decadent.org.uk> - 2017-01-27 03:00 +0100
            Bug#843349: linux-image-4.7.0-1-amd64: Intermittently high system load, sluggish response, no /proc/<pid>/stat utime,stime,etc. reported Tom Lee <debian@tomlee.co> - 2017-01-27 03:20 +0100
              Bug#843349: linux-image-4.7.0-1-amd64: Intermittently high system load, sluggish response, no /proc/<pid>/stat utime,stime,etc. reported Tom Lee <debian@tomlee.co> - 2017-01-27 03:40 +0100

#55717 — Bug#843349: linux-image-4.7.0-1-amd64: Intermittently high system load, sluggish response, no /proc/<pid>/stat utime,stime,etc. reported

[Multipart message — attachments visible in raw view] — view raw

Control: tag -1 moreinfo

On Sun, 2016-11-06 at 00:02 -0700, Tom Lee wrote:
[...]
> Downgrading to linux-image-4.6.0-1-amd64 fixed all symptoms. Haven't yet
> tried 4.8.0-1 from unstable, not sure if it's impacted.
[...]

Please do.

Ben.

-- 
Ben Hutchings
Nothing is ever a complete failure; it can always serve as a bad
example.

[toc] | [next] | [standalone]

#55801

[Multipart message — attachments visible in raw view] — view raw

Tried 4.8.0-1 with similar results. Perhaps slightly better, but not much.

$ uname -a
Linux desktop 4.8.0-1-amd64 #1 SMP Debian 4.8.5-1 (2016-10-28) x86_64
GNU/Linux

Like 4.7, can't see what's hogging the CPUs as per-process CPU stats don't
appear to be correctly reported in /proc/<pid>/stat.

4.6.x continues to be perfect with respect to both overall performance and
the correctness of /proc/<pid>/stat.


On Sat, Nov 12, 2016 at 8:23 PM, Ben Hutchings <ben@decadent.org.uk> wrote:

> Control: tag -1 moreinfo
>
> On Sun, 2016-11-06 at 00:02 -0700, Tom Lee wrote:
> [...]
> > Downgrading to linux-image-4.6.0-1-amd64 fixed all symptoms. Haven't yet
> > tried 4.8.0-1 from unstable, not sure if it's impacted.
> [...]
>
> Please do.
>
> Ben.
>
> --
> Ben Hutchings
> Nothing is ever a complete failure; it can always serve as a bad
> example.
>
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

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

#55802

[Multipart message — attachments visible in raw view] — view raw

Also potentially relevant: kworker/0:0 has 421h on-cpu time reported per
htop (the TIME+ column) and top. /proc/<pid>/stat output for PID=4
(kworker/0:0) vs PID=63 (kworker/1:1):

tom@desktop ~ $ cat /proc/63/stat
63 (kworker/1:1) S 2 0 0 0 -1 69238880 0 0 0 0 0 0 0 0 20 0 1 0 82 0 0
18446744073709551615 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 1 0 0 184 0 0 0 0
0 0 0 0 0 0
tom@desktop ~ $ cat /proc/4/stat
4 (kworker/0:0) S 2 0 0 0 -1 69238880 0 0 0 0 151836336 0 0 0 20 0 1 0 10 0
0 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 0 0 0 0 0 0 0 0
0 0 0 0 0 0

In fact, kworker:0:0 seems to be the only process with on-cpu stats
reported (forgive the shell abuse, quick and dirty):

$ for pid in $(ls /proc | awk '/^[0-9]*$/'); do [ -d /proc/$pid ] && awk
'$14 != "0" { print $2 }' /proc/$pid/stat; done
(kworker/0:0)
$


On Sun, Nov 20, 2016 at 2:12 PM, Tom Lee <debian@tomlee.co> wrote:

> Tried 4.8.0-1 with similar results. Perhaps slightly better, but not much.
>
> $ uname -a
> Linux desktop 4.8.0-1-amd64 #1 SMP Debian 4.8.5-1 (2016-10-28) x86_64
> GNU/Linux
>
> Like 4.7, can't see what's hogging the CPUs as per-process CPU stats don't
> appear to be correctly reported in /proc/<pid>/stat.
>
> 4.6.x continues to be perfect with respect to both overall performance and
> the correctness of /proc/<pid>/stat.
>
>
> On Sat, Nov 12, 2016 at 8:23 PM, Ben Hutchings <ben@decadent.org.uk>
> wrote:
>
>> Control: tag -1 moreinfo
>>
>> On Sun, 2016-11-06 at 00:02 -0700, Tom Lee wrote:
>> [...]
>> > Downgrading to linux-image-4.6.0-1-amd64 fixed all symptoms. Haven't yet
>> > tried 4.8.0-1 from unstable, not sure if it's impacted.
>> [...]
>>
>> Please do.
>>
>> Ben.
>>
>> --
>> Ben Hutchings
>> Nothing is ever a complete failure; it can always serve as a bad
>> example.
>>
>>
>
>
> --
> *Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
>
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

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

#56761

[Multipart message — attachments visible in raw view] — view raw

Just an update: I am still encountering similar performance issues with the
4.9.0-1 kernel that was recently promoted to testing. In fact, the 4.9.0-1
kernel may be the worst yet in terms of this specific issue, with IntelliJ
starting so slowly as to be effectively unusable. One time the entire
system appeared to become completely unresponsive & a hard reset was
required.

The most recent kernel with which I've experienced problems:

$ apt-cache show linux-image-4.9.0-1-amd64
Package: linux-image-4.9.0-1-amd64
Source: linux-signed (4)
Version: 4.9.2-2
Installed-Size: 183299

This problem does *not* seem to occur with a vanilla 4.9.2 kernel, implying
something Debian-specific:

$ uname -a
Linux desktop.local 4.9.2 #1 SMP Wed Jan 25 04:28:29 PST 2017 x86_64
GNU/Linux

If you're aware of any Debian patches that might be suspect, I'm happy to
try some custom builds. Reproducing the issue is trivial on my end when a
kernel is "bad".


On Sun, Nov 20, 2016 at 2:24 PM, Tom Lee <debian@tomlee.co> wrote:

> Also potentially relevant: kworker/0:0 has 421h on-cpu time reported per
> htop (the TIME+ column) and top. /proc/<pid>/stat output for PID=4
> (kworker/0:0) vs PID=63 (kworker/1:1):
>
> tom@desktop ~ $ cat /proc/63/stat
> 63 (kworker/1:1) S 2 0 0 0 -1 69238880 0 0 0 0 0 0 0 0 20 0 1 0 82 0 0
> 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 1 0 0 184 0 0 0 0
> 0 0 0 0 0 0
> tom@desktop ~ $ cat /proc/4/stat
> 4 (kworker/0:0) S 2 0 0 0 -1 69238880 0 0 0 0 151836336 0 0 0 20 0 1 0 10
> 0 0 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0
>
> In fact, kworker:0:0 seems to be the only process with on-cpu stats
> reported (forgive the shell abuse, quick and dirty):
>
> $ for pid in $(ls /proc | awk '/^[0-9]*$/'); do [ -d /proc/$pid ] && awk
> '$14 != "0" { print $2 }' /proc/$pid/stat; done
> (kworker/0:0)
> $
>
>
> On Sun, Nov 20, 2016 at 2:12 PM, Tom Lee <debian@tomlee.co> wrote:
>
>> Tried 4.8.0-1 with similar results. Perhaps slightly better, but not much.
>>
>> $ uname -a
>> Linux desktop 4.8.0-1-amd64 #1 SMP Debian 4.8.5-1 (2016-10-28) x86_64
>> GNU/Linux
>>
>> Like 4.7, can't see what's hogging the CPUs as per-process CPU stats
>> don't appear to be correctly reported in /proc/<pid>/stat.
>>
>> 4.6.x continues to be perfect with respect to both overall performance
>> and the correctness of /proc/<pid>/stat.
>>
>>
>> On Sat, Nov 12, 2016 at 8:23 PM, Ben Hutchings <ben@decadent.org.uk>
>> wrote:
>>
>>> Control: tag -1 moreinfo
>>>
>>> On Sun, 2016-11-06 at 00:02 -0700, Tom Lee wrote:
>>> [...]
>>> > Downgrading to linux-image-4.6.0-1-amd64 fixed all symptoms. Haven't
>>> yet
>>> > tried 4.8.0-1 from unstable, not sure if it's impacted.
>>> [...]
>>>
>>> Please do.
>>>
>>> Ben.
>>>
>>> --
>>> Ben Hutchings
>>> Nothing is ever a complete failure; it can always serve as a bad
>>> example.
>>>
>>>
>>
>>
>> --
>> *Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
>>
>>
>
>
> --
> *Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
>
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

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

#56781

[Multipart message — attachments visible in raw view] — view raw

On Wed, 2017-01-25 at 17:52 -0800, Tom Lee wrote:
> Just an update: I am still encountering similar performance issues with the
> 4.9.0-1 kernel that was recently promoted to testing. In fact, the 4.9.0-1
> kernel may be the worst yet in terms of this specific issue, with IntelliJ
> starting so slowly as to be effectively unusable. One time the entire
> system appeared to become completely unresponsive & a hard reset was
> required.
> 
> The most recent kernel with which I've experienced problems:
> 
> $ apt-cache show linux-image-4.9.0-1-amd64
> Package: linux-image-4.9.0-1-amd64
> Source: linux-signed (4)
> Version: 4.9.2-2
> Installed-Size: 183299
> 
> This problem does *not* seem to occur with a vanilla 4.9.2 kernel, implying
> something Debian-specific:
> 
> $ uname -a
> Linux desktop.local 4.9.2 #1 SMP Wed Jan 25 04:28:29 PST 2017 x86_64
> GNU/Linux
> 
> If you're aware of any Debian patches that might be suspect, I'm happy to
> try some custom builds. Reproducing the issue is trivial on my end when a
> kernel is "bad".
[...]

I think that the difference is more likely to be in the configuration,
rather than the patches we apply.

Some other people followed up to your bug report suggesting there might
be a BIOS bug affecting behaviour after a warm reboot, but not booting
from power-off:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843349#17
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843349#32

(Unfortunately I don't see any BIOS updates available for this model.)
Have you tried booting one of the newer kernel versions from power-off?

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.

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

#56782

[Multipart message — attachments visible in raw view] — view raw

Oops, somehow missed those follow-ups. Thanks, I'll catch up.

Have you tried booting one of the newer kernel versions from power-off?


I'll be sure to give that a go, thanks.


On Thu, Jan 26, 2017 at 5:54 PM, Ben Hutchings <ben@decadent.org.uk> wrote:

> On Wed, 2017-01-25 at 17:52 -0800, Tom Lee wrote:
> > Just an update: I am still encountering similar performance issues with
> the
> > 4.9.0-1 kernel that was recently promoted to testing. In fact, the
> 4.9.0-1
> > kernel may be the worst yet in terms of this specific issue, with
> IntelliJ
> > starting so slowly as to be effectively unusable. One time the entire
> > system appeared to become completely unresponsive & a hard reset was
> > required.
> >
> > The most recent kernel with which I've experienced problems:
> >
> > $ apt-cache show linux-image-4.9.0-1-amd64
> > Package: linux-image-4.9.0-1-amd64
> > Source: linux-signed (4)
> > Version: 4.9.2-2
> > Installed-Size: 183299
> >
> > This problem does *not* seem to occur with a vanilla 4.9.2 kernel,
> implying
> > something Debian-specific:
> >
> > $ uname -a
> > Linux desktop.local 4.9.2 #1 SMP Wed Jan 25 04:28:29 PST 2017 x86_64
> > GNU/Linux
> >
> > If you're aware of any Debian patches that might be suspect, I'm happy to
> > try some custom builds. Reproducing the issue is trivial on my end when a
> > kernel is "bad".
> [...]
>
> I think that the difference is more likely to be in the configuration,
> rather than the patches we apply.
>
> Some other people followed up to your bug report suggesting there might
> be a BIOS bug affecting behaviour after a warm reboot, but not booting
> from power-off:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843349#17
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843349#32
>
> (Unfortunately I don't see any BIOS updates available for this model.)
> Have you tried booting one of the newer kernel versions from power-off?
>
> Ben.
>
> --
> Ben Hutchings
> Design a system any fool can use, and only a fool will want to use it.
>



-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

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

#56783

[Multipart message — attachments visible in raw view] — view raw

Alrighty, having read through the other responses I'm inclined to agree
something's not playing nice with certain hardware:

I think that the difference is more likely to be in the configuration,
> rather than the patches we apply.
>
> As in the kernel config? I guess that's possible. I think I built my
"good" vanilla 4.9 kernel using the debian 4.6 config. Perhaps in addition
the booting-from-power-off, maybe worth my time to try another vanilla 4.9
build using the debian 4.9 config to see if things get miserable again.


On Thu, Jan 26, 2017 at 6:10 PM, Tom Lee <debian@tomlee.co> wrote:

> Oops, somehow missed those follow-ups. Thanks, I'll catch up.
>
> Have you tried booting one of the newer kernel versions from power-off?
>
>
> I'll be sure to give that a go, thanks.
>
>
> On Thu, Jan 26, 2017 at 5:54 PM, Ben Hutchings <ben@decadent.org.uk>
> wrote:
>
>> On Wed, 2017-01-25 at 17:52 -0800, Tom Lee wrote:
>> > Just an update: I am still encountering similar performance issues with
>> the
>> > 4.9.0-1 kernel that was recently promoted to testing. In fact, the
>> 4.9.0-1
>> > kernel may be the worst yet in terms of this specific issue, with
>> IntelliJ
>> > starting so slowly as to be effectively unusable. One time the entire
>> > system appeared to become completely unresponsive & a hard reset was
>> > required.
>> >
>> > The most recent kernel with which I've experienced problems:
>> >
>> > $ apt-cache show linux-image-4.9.0-1-amd64
>> > Package: linux-image-4.9.0-1-amd64
>> > Source: linux-signed (4)
>> > Version: 4.9.2-2
>> > Installed-Size: 183299
>> >
>> > This problem does *not* seem to occur with a vanilla 4.9.2 kernel,
>> implying
>> > something Debian-specific:
>> >
>> > $ uname -a
>> > Linux desktop.local 4.9.2 #1 SMP Wed Jan 25 04:28:29 PST 2017 x86_64
>> > GNU/Linux
>> >
>> > If you're aware of any Debian patches that might be suspect, I'm happy
>> to
>> > try some custom builds. Reproducing the issue is trivial on my end when
>> a
>> > kernel is "bad".
>> [...]
>>
>> I think that the difference is more likely to be in the configuration,
>> rather than the patches we apply.
>>
>> Some other people followed up to your bug report suggesting there might
>> be a BIOS bug affecting behaviour after a warm reboot, but not booting
>> from power-off:
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843349#17
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843349#32
>>
>> (Unfortunately I don't see any BIOS updates available for this model.)
>> Have you tried booting one of the newer kernel versions from power-off?
>>
>> Ben.
>>
>> --
>> Ben Hutchings
>> Design a system any fool can use, and only a fool will want to use it.
>>
>
>
>
> --
> *Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
>
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web