Kernel prepatch 3.10-rc1

Posted May 16, 2013 0:08 UTC (Thu) by nowster (subscriber, #67)
Parent article: Kernel prepatch 3.10-rc1

And weirdness with ps possibly related to procfs or NOHZ changes:

$ ps -u
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
pm       14902  733  0.1  24500  7088 pts/1    Ss+  00:34 181:35 -bash
pm       15375 12600  0.1 24484  7076 pts/0    Ss   00:58  71:24 -bash

top also reports all process as using 0%, 100%, 200% (up to the number of CPUs available × 100%), and vmstat reports 100% system and 0% for everything else.

Kernel prepatch 3.10-rc1

Posted May 16, 2013 0:32 UTC (Thu) by dlang (guest, #313) [Link] (2 responses)

I'm not sure this is a change.

Top has reported processes using >100% cpu on multi core machines for years

vmstat scales it's usage based on 100% of total cpu power, no matter how many CPUs in the system.

now, if the stats are now incorrect, that could be related to the changes. My understanding is that issues like this are somewhat expected from the NOHZ changes and they are working to find and fix them as things get more widespread testing to flush out problem cases.

Kernel prepatch 3.10-rc1

Posted May 16, 2013 0:45 UTC (Thu) by nowster (subscriber, #67) [Link] (1 responses)

Like many of your recent posts, this one assumes the original poster is an idiot.

top is reporting integer multiples of 100% only, vmstat is pegged on 100% sys, and ps is reporting total fiction. This feels like either a format change for the procfs stats or a problem in the scheduler's reporting.

Kernel prepatch 3.10-rc1

Posted May 16, 2013 0:53 UTC (Thu) by dlang (guest, #313) [Link]

the example posted shows cpu results that are not multiples of 100%, so we are not seeing quite the same thing here.

assuming ignorance is not the same as assuming someone is an idiot. When I first ran across the >100% cpu and inconsistant between different tools other people had known about it for years, but it looked like a bug to me, so I see no reason why other folks could not be in the same situation today.

But as I said, it's not at all surprising to see bugs in the scheduler's reporting of time with the NOHZ changes, I seem to remember that the article talking about them indicated that they were still working to nail down and fix bugs in the reporting side.