public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Williams <pwil3058@bigpond.net.au>
To: Con Kolivas <kernel@kolivas.org>
Cc: Al Boldi <a1426z@gawab.com>,
	linux-kernel@vger.kernel.org, Pavel Machek <pavel@ucw.cz>,
	Jan Engelhardt <jengelh@linux01.gwdg.de>
Subject: Re: Incorrect CPU process accounting using         CONFIG_HZ=100
Date: Thu, 29 Jun 2006 10:25:12 +1000	[thread overview]
Message-ID: <44A31DE8.20100@bigpond.net.au> (raw)
In-Reply-To: <cone.1151538362.930767.14982.501@kolivas.org>

Con Kolivas wrote:
> Peter Williams writes:
> 
>> Al Boldi wrote:
>>> Peter Williams wrote:
> 
>>> twice:
>>>     1. for external proc monitoring, using a probed approach
>>>     2. for scheduling, using an inlined approach
>>
>> Not exactly (e.g. there's no separation between user and sys time 
>> available in line) but the possibilities are there.
>>
>>>
>>> Wouldn't merging the two approaches be in the interest of conserving 
>>> cpu resources, while at the same time reflecting an accurate view of 
>>> cpu utilization?
>>
>> I think that this would be a worthwhile endeavour once/if 
>> sched_clock() is fixed.  This is especially the case as CPUs get 
>> faster as many tasks may run to completion in less than a tick.
> 
> That may not be as simple as it seems. To properly account system v user 
> time using the sched_clock we'd have to hook into arch dependant asm 
> code to know when entering and exiting kernel context. That is far more 
> invasive than the simple on/off runqueue timing we currently do for 
> scheduling accounting.

Yes, it is a problem and we may have to do something approximate like 
counting ticks for sys time and subtracting that from the total to get 
user time when reporting the times to user space (only a bit more 
complex to make sure we don't end up with negative times).

How is it intended to handle this problem in the tickless kernel?

Peter
PS It's all moot until sched_clock() is fixed anyway.
PPS Recent kernels (-mm ones at least) keep a sched_time in nsecs for 
each task but I've no idea what it's used for.
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

  reply	other threads:[~2006-06-29  0:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-21 14:16 Incorrect CPU process accounting using CONFIG_HZ=100 Al Boldi
2006-06-22  5:46 ` Jan Engelhardt
2006-06-22 17:36   ` Al Boldi
2006-06-26 16:02     ` Pavel Machek
2006-06-27 12:32       ` Al Boldi
2006-06-27 13:02         ` Con Kolivas
2006-06-27 23:52           ` Peter Williams
2006-06-28 20:06             ` Al Boldi
2006-06-28 23:23               ` Peter Williams
2006-06-28 23:46                 ` Con Kolivas
2006-06-29  0:25                   ` Peter Williams [this message]
2006-06-29  1:10                     ` Con Kolivas
2006-06-29  7:29                     ` Pavel Machek

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=44A31DE8.20100@bigpond.net.au \
    --to=pwil3058@bigpond.net.au \
    --cc=a1426z@gawab.com \
    --cc=jengelh@linux01.gwdg.de \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox