[Bugme-new] [Bug 16559] New: /proc/<pid>/stat incorrect user and kernel time accounting

bugzilla-daemon at bugzilla.kernel.org bugzilla-daemon at bugzilla.kernel.org
Tue Aug 10 16:56:53 PDT 2010


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

           Summary: /proc/<pid>/stat incorrect user and kernel time
                    accounting
           Product: Timers
           Version: 2.5
    Kernel Version: 2.6.33, 2.6.34, 2.6.35
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Other
        AssignedTo: johnstul at us.ibm.com
        ReportedBy: sysman at etherpilot.com
        Regression: No


Created an attachment (id=27401)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=27401)
ver_linux output from one affected system

In a program intensive in user time CPU, the 'utime' field in /proc/<pid>/stat
becomes freezed at some point (utime will never be incremented again) and the
'stime' starts to (wrongly) receive the increments instead.

At the same time /proc/stat correctly assings the CPU spent as user mode time
(in fact, commands like "top" still show proper global CPU reports). But this
problem causes getrusage() to return incorrect values, reporting user mode time
as kernel time for the running process (for example, the GNU gmp library
benchmark reports wrong timings).

Affected kernel versions: 2.6.33, 2.6.34, 2.6.35
Last kernel version not affected by this bug: 2.6.32
Machines known to reproduce the bug: Core 2 Duo E8500, Atom N270, Pentium D.

Steps to reproduce the problem:

1) Make a tiny C program doing an infinite loop and run it

2) Examine /proc/PID/stat:
   - After 2-4 minutes, the User CPU time becomes stalled (in a value from
about 15000 to 25000) and will never increase again.
   - At the same time, the Kernel CPU time incorrectly begins to increase,
reporting 100% of the CPU ticks.
   - However /proc/stat correctly continues reporting the CPU being spent as
User time.

In example bellow, the user time becomes freezed at "21533" after just 215.33
seconds:

ciri at quark:/proc/12096$ cat stat | awk '{ print $14 " " $15 }' ; head -1
../stat | awk '{ print $2 " " $4 }' ; date
20549 21
116668 6587
Mon Aug  9 23:53:53 CEST 2010

ciri at quark:/proc/12096$ cat stat | awk '{ print $14 " " $15 }' ; head -1
../stat | awk '{ print $2 " " $4 }' ; date
21533 21
117656 6588
Mon Aug  9 23:54:03 CEST 2010

ciri at quark:/proc/12096$ cat stat | awk '{ print $14 " " $15 }' ; head -1
../stat | awk '{ print $2 " " $4 }' ; date
21533 639
118275 6589
Mon Aug  9 23:54:09 CEST 2010

ciri at quark:/proc/12096$ cat stat | awk '{ print $14 " " $15 }' ; head -1
../stat | awk '{ print $2 " " $4 }' ; date
21533 1795
119434 6590
Mon Aug  9 23:54:20 CEST 2010

ciri at quark:/proc/12096$ cat stat | awk '{ print $14 " " $15 }' ; head -1
../stat | awk '{ print $2 " " $4 }' ; date
21533 16337
134138 6670
Mon Aug  9 23:56:46 CEST 2010

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


More information about the Bugme-new mailing list