All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Jan Glauber <jang@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>, Paul Mackerras <paulus@samba.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	LKML <linux-kernel@vger.kernel.org>,
	vatsa@linux.vnet.ibm.com, mschwid2@linux.vnet.ibm.com,
	efault@gmx.de, dmitry.adamushko@gmail.com, anton@samba.org
Subject: Re: [PATCH] virtual sched_clock() for s390
Date: Mon, 23 Jul 2007 15:24:08 +0200	[thread overview]
Message-ID: <1185197048.7816.19.camel@localhost> (raw)
In-Reply-To: <1185182149.5783.11.camel@localhost.localdomain>

On Mon, 2007-07-23 at 09:15 +0000, Jan Glauber wrote:
> > > As with s390, 64-bit PowerPC also uses CONFIG_VIRT_CPU_ACCOUNTING. 
> > > That affects how tsk->utime and tsk->stime are accumulated (we call 
> > > account_user_time and account_system_time directly rather than calling 
> > > update_process_times) as well as the system hardirq/softirq time, idle 
> > > time, and stolen time.
> > 
> > tsk->utime and tsk->stime is only used for a single purpose: to 
> > determine the 'split' factor of how to split up the precise total time 
> > between user and system time.

At least for s390 and powerpc the utime and stime already contain a very
precise value how much time was spent in the user and system context.
For s390 the granularity is a microsecond. The other values nice, idle,
iowait, irq, softirq and steal are precise as well.

> > > When you say "precise task statistics for /proc", where are they 
> > > accumulated?  I don't see any changes to the way that tsk->utime and 
> > > ctime are computed.
> > 
> > we now use p->se.sum_exec_runtime that measures (in nanoseconds) the 
> > precise amount of time spent executing (sum of system and user time) - 
> > and ->stime and ->utime is used to determine the 'split'. [this allows 
> > us to gather ->stime and ->utime via low-resolution sampling, while 
> > keeping the 'total' precise. Accounting at every system entry point 
> > would be quite expensive on most platforms.]

With the exact accounting of utime and stime that would mean that
p->se.sum_exec_runtime is utime + stime, no?
Precise Accounting at every cpu context switch has some cost, but for
s390 it is not as bad as it sounds. We do 2 store-cpu-timer (STPT)
instructions, 2 64 bit adds and 2 64 bit subtracts. In terms of cycles
it is less than 30 cycles on each system entry on the latest machine.

> Using se.sum_exec_runtime to generate ->utime and ->stime breaks
> the process accounting we have on s390 (and probably on PowerPC too).
> With CONFIG_VIRT_CPU_ACCOUNTING we already have precise values in
> ->utime and ->stime. Can we make the calculation of the CFS-based time
> values conditional by CONFIG_VIRT_CPU_ACCOUNTING?

Imho, we just have to update utime and stime when the process accounting
values are requested and set se.sum_exec_runtime to the sum of utime and
stime for CONFIG_VIRT_CPU_ACCOUNTING=y.

-- 
blue skies,
  Martin.

"Reality continues to ruin my life." - Calvin.




      reply	other threads:[~2007-07-23 13:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-19 10:57 [PATCH] virtual sched_clock() for s390 Jan Glauber
2007-07-19 15:29 ` Jeremy Fitzhardinge
2007-07-19 15:48   ` Srivatsa Vaddagiri
2007-07-19 16:00   ` Ingo Molnar
2007-07-19 19:20     ` Jan Glauber
2007-07-19 19:38       ` Ingo Molnar
2007-07-19 21:07         ` Jan Glauber
2007-07-20  1:01     ` Paul Mackerras
2007-07-20  6:03       ` Jeremy Fitzhardinge
2007-07-20  7:22       ` Ingo Molnar
2007-07-23  9:15         ` Jan Glauber
2007-07-23 13:24           ` Martin Schwidefsky [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1185197048.7816.19.camel@localhost \
    --to=schwidefsky@de.ibm.com \
    --cc=anton@samba.org \
    --cc=dmitry.adamushko@gmail.com \
    --cc=efault@gmx.de \
    --cc=jang@linux.vnet.ibm.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mschwid2@linux.vnet.ibm.com \
    --cc=paulus@samba.org \
    --cc=vatsa@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.