lkml.org 
[lkml]   [2007]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH for testing] Re: Decreasing stime running confuses top
    Date
    Am Donnerstag, 4. Oktober 2007 schrieb Chuck Ebbert:
    > On 10/04/2007 04:00 PM, Christian Borntraeger wrote:
    > > Am Donnerstag, 4. Oktober 2007 schrieb Chuck Ebbert:
    > >> Is CONFIG_VIRT_CPU_ACCOUNTING set?
    > >
    > > This is s390 and powerpc only, so the answer is probably no ;-)
    > >
    >
    > The code in fs/proc/array.c is... interesting.

    Short history what I know about this file:
    after 2.6.22 the accounting was changes to use sched_clock and to use stime
    and utime only for the split. This is where task_utime and task_stime were
    introduced. See the code in 2.6.23-rc1.
    Unfortunately this broke the accouting on s390 which already has precise
    numbers in utime and stime. So the code was partially reverted to use stime
    and utime again where appropriate, which are of type cputime_t.

    >
    > 1. task_stime() converts p->se.sum_exec_runtime to a clock_t

    correct.

    >
    > 2. it calls task_utime() which does the same thing (can it change
    > between the two reads?), does some calculations that yield a
    > clock_t, turns the result into a cputime and returns that
    >
    > 3. task_stime() then converts that result back into a clock_t and
    > uses it!

    These conversions can reduce the accuracy to jiffie resolution, but should not
    make the value non-monotonic. I dont think that here is the problem.

    But: it seems that p->se.sum_exec_runtime can change indeed. That would
    explain stime going backward, if sum_exec_runtime was increases in the middle
    of the calculation.
    The logic of task_stime and task_utime was introduced by
    http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b27f03d4bdc145a09fb7b0c0e004b29f1ee555fa


    Frans can you test this patch if this makes stime and utime monotic again?

    It basically reverts the rest of b27f03d4bdc145a09fb7b0c0e004b29f1ee555fa and
    should restore the 2.6.22 behavior. The process time is used from tasks utime
    and stime instead of the scheduler clock. That means, in general after a long
    period of time, it is less accurate than the current time and behaves like
    2.6.22.

    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    ---
    array.c | 37 -------------------------------------
    1 file changed, 37 deletions(-)


    diff --git a/fs/proc/array.c b/fs/proc/array.c
    index ee4814d..e42c76e 100644
    --- a/fs/proc/array.c
    +++ b/fs/proc/array.c
    @@ -323,7 +323,6 @@ int proc_pid_status(struct task_struct *task, char
    *buffer)
    /*
    * Use precise platform statistics if available:
    */
    -#ifdef CONFIG_VIRT_CPU_ACCOUNTING
    static cputime_t task_utime(struct task_struct *p)
    {
    return p->utime;
    @@ -333,42 +332,6 @@ static cputime_t task_stime(struct task_struct *p)
    {
    return p->stime;
    }
    -#else
    -static cputime_t task_utime(struct task_struct *p)
    -{
    - clock_t utime = cputime_to_clock_t(p->utime),
    - total = utime + cputime_to_clock_t(p->stime);
    - u64 temp;
    -
    - /*
    - * Use CFS's precise accounting:
    - */
    - temp = (u64)nsec_to_clock_t(p->se.sum_exec_runtime);
    -
    - if (total) {
    - temp *= utime;
    - do_div(temp, total);
    - }
    - utime = (clock_t)temp;
    -
    - return clock_t_to_cputime(utime);
    -}
    -
    -static cputime_t task_stime(struct task_struct *p)
    -{
    - clock_t stime;
    -
    - /*
    - * Use CFS's precise accounting. (we subtract utime from
    - * the total, to make sure the total observed by userspace
    - * grows monotonically - apps rely on that):
    - */
    - stime = nsec_to_clock_t(p->se.sum_exec_runtime) -
    - cputime_to_clock_t(task_utime(p));
    -
    - return clock_t_to_cputime(stime);
    -}
    -#endif

    static int do_task_stat(struct task_struct *task, char *buffer, int whole)
    {
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/
    \
     
     \ /
      Last update: 2007-10-04 23:23    [W:0.027 / U:1.512 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site