Re: [PATCH for testing] Re: Decreasing stime running confuses top

2007-10-08 Thread Ingo Molnar
* Christian Borntraeger <[EMAIL PROTECTED]> 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

Re: [PATCH for testing] Re: Decreasing stime running confuses top

2007-10-08 Thread Christian Borntraeger
Am Freitag, 5. Oktober 2007 schrieb Frans Pop: > On Thursday 04 October 2007, you wrote: > > 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 > > behavi

Re: [PATCH for testing] Re: Decreasing stime running confuses top

2007-10-05 Thread Frans Pop
On Thursday 04 October 2007, you wrote: > 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 inste

Re: [PATCH for testing] Re: Decreasing stime running confuses top

2007-10-05 Thread Frans Pop
On Friday 05 October 2007, Chuck Ebbert wrote: > procfs: Don't read runtime twice when computing task's stime > > Current code reads p->se.sum_exec_runtime twice and goes through > multiple type conversions to calculate stime. Read it once and > skip some of the conversions. > > Signed-off-by: Chuc

Re: [PATCH for testing] Re: Decreasing stime running confuses top

2007-10-05 Thread Luca
On 10/5/07, Chuck Ebbert <[EMAIL PROTECTED]> wrote: > On 10/04/2007 05:10 PM, Christian Borntraeger wrote: > > > > > Alternative patch: > > procfs: Don't read runtime twice when computing task's stime > > Current code reads p->se.sum_exec_runtime twice and goes through > multiple type conversions

Re: [PATCH for testing] Re: Decreasing stime running confuses top

2007-10-04 Thread Christian Borntraeger
Am Freitag, 5. Oktober 2007 schrieb Chuck Ebbert: > On 10/04/2007 05:10 PM, Christian Borntraeger wrote: > > > > > Alternative patch: > > procfs: Don't read runtime twice when computing task's stime > > Current code reads p->se.sum_exec_runtime twice and goes through > multiple type conversion

Re: [PATCH for testing] Re: Decreasing stime running confuses top

2007-10-04 Thread Chuck Ebbert
On 10/04/2007 05:10 PM, Christian Borntraeger wrote: > Alternative patch: procfs: Don't read runtime twice when computing task's stime Current code reads p->se.sum_exec_runtime twice and goes through multiple type conversions to calculate stime. Read it once and skip some of the conversions.

[PATCH for testing] Re: Decreasing stime running confuses top

2007-10-04 Thread Christian Borntraeger
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

Re: Decreasing stime running confuses top

2007-10-04 Thread 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. 1. task_stime() converts p->se.s

Re: Decreasing stime running confuses top

2007-10-04 Thread Christian Borntraeger
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 ;-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: Decreasing stime running confuses top

2007-10-04 Thread Chuck Ebbert
On 10/04/2007 03:19 PM, Luca Tettamanti wrote: >> The latter seems to be utime ...decreasing. No wonder if >> arithmetics will give strange results (probably top is using >> unsigned delta?)... > Hmm, minor miscounting from my side, stime seems more appropriate... So, is it nor

Re: Decreasing stime running confuses top (was: top displaying 9999% CPU usage)

2007-10-04 Thread Luca Tettamanti
Il Thu, Oct 04, 2007 at 01:32:44AM +0200, Frans Pop ha scritto: > On Wednesday 03 October 2007, you wrote: > > On Wed, Oct 03, 2007 at 09:27:41PM +0200, Frans Pop wrote: > > > On Wednesday 03 October 2007, you wrote: > > > > On Wed, 3 Oct 2007, Ilpo Järvinen wrote: > > > > > On Wed, 3 Oct 2007, Fr

Re: Decreasing stime running confuses top (was: top displaying 9999% CPU usage)

2007-10-03 Thread Frans Pop
On Wednesday 03 October 2007, you wrote: > On Wed, Oct 03, 2007 at 09:27:41PM +0200, Frans Pop wrote: > > On Wednesday 03 October 2007, you wrote: > > > On Wed, 3 Oct 2007, Ilpo Järvinen wrote: > > > > On Wed, 3 Oct 2007, Frans Pop wrote: > > > > > The only change is in 2 consecutive columns: "2911

Re: Decreasing stime running confuses top (was: top displaying 9999% CPU usage)

2007-10-03 Thread Willy Tarreau
On Wed, Oct 03, 2007 at 09:27:41PM +0200, Frans Pop wrote: > On Wednesday 03 October 2007, you wrote: > > On Wed, 3 Oct 2007, Ilpo Järvinen wrote: > > > On Wed, 3 Oct 2007, Frans Pop wrote: > > > > The only change is in 2 consecutive columns: "2911 502" -> "2912 > > > > 500". Is processor usage cal

Decreasing stime running confuses top (was: top displaying 9999% CPU usage)

2007-10-03 Thread Frans Pop
On Wednesday 03 October 2007, you wrote: > On Wed, 3 Oct 2007, Ilpo Järvinen wrote: > > On Wed, 3 Oct 2007, Frans Pop wrote: > > > The only change is in 2 consecutive columns: "2911 502" -> "2912 > > > 500". Is processor usage calculated from those? Can someone explain > > > how? > > > > The latter