lkml.org 
[lkml]   [2007]   [Oct]   [8]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
    /
    DateMon, 8 Oct 2007 19:00:23 +0200
    FromIngo Molnar <>
    SubjectRe: [PATCH for testing] Re: Decreasing stime running confuses top
    * Christian Borntraeger <borntraeger@de.ibm.com> wrote:
    
    > Why does it still shows numbers going backwards? I guess the sampled 
    > values for stime and utime change in flight between task_utime and 
    > task_stime are called. Lets say utime will be increased. Given the 
    > same sum_exec_runtime that means that the result of task_stime() will 
    > get smaller at this point.
    > 
    > So Chucks patch only deals with sum_exec_runtime changing.
    
    basically sum_exec_runtime is split up to form a precise utime/stime, 
    using the stime/utime ratio as the factor.
    
    > > It seems to me that this patch would be the best option for 2.6.23.
    > 
    > Ingo, do you have any opinion about how to proceed?
    
    the problem occurs when there's a different "split" dictated by 
    p->stime/p->utime. The sum of stime+utime as reported should be 
    monotonic, but the individual components may not. (the reason is that we 
    have a precise "sum" for free, given by the scheduler, but we do not 
    want the overhead of per-syscall timestamps to get a precise stime/utime 
    numbers. So we sample p->stime and p->utime from the scheduler tick.)
    
    	Ingo
    -
    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-08 19:03    [from the cache]
    ©2003-2008