All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: holzheu@linux.vnet.ibm.com
Cc: Shailabh Nagar <nagar1234@in.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Venkatesh Pallipadi <venki@google.com>,
	Suresh Siddha <suresh.b.siddha@intel.com>,
	Ingo Molnar <mingo@elte.hu>, Oleg Nesterov <oleg@redhat.com>,
	John stultz <johnstul@us.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Balbir Singh <balbir@linux.vnet.ibm.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Roland McGrath <roland@redhat.com>,
	linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [RFC][PATCH v2 1/7] taskstats: Add new taskstats command TASKSTATS_CMD_ATTR_PIDS
Date: Mon, 15 Nov 2010 18:21:45 +0100	[thread overview]
Message-ID: <1289841705.2109.513.camel@laptop> (raw)
In-Reply-To: <1289840968.1916.85.camel@holzheu-laptop>

On Mon, 2010-11-15 at 18:09 +0100, Michael Holzheu wrote:

> > That you should not use sched_clock(),
> 
> What should we use instead?

Depends on what you want, look at kernel/sched_clock.c

> > What does last departed mean? That is what timeline are you counting in?
> > Do you want time as tasks see it, or time as your wallclock sees it?
> 
> "last_depart" should be the time stamp, where the task has left a CPU
> the last time.
> 
> We assume that we can compare "last_depart" with "time_ns" in the
> taskstats structure,

I think you assume I actually know anything about taskstat :-), its the
thing I always say =n to in my config file and have so far happily
ignored all code of.

>  if we use task_rq(t)->clock for last_depart and
> sched_clock() for stats->time_ns.

Then you're up shit creek because rq->clock doesn't necessarily have any
correlation to sched_clock().

>  We also assume that we get wallclock
> intervals in nanoseconds, if we look at two sched_clock() timestamps.

Invalid assumption.

> "stats->time_ns" is used as timestamp for the next snapshot query and
> for calculation of the snapshot interval time. So there are three
> important timestamps:
> * struct task_struct:
>   sched_info.last_depart: Last time task has left CPU

So you're essentially replicating the data in
sched_entity::statistics::wait_start ?

> * struct taskstats:
>   time_ns: Timestamp where taskstats data is generated
> * sturuct cmd_pids:
>   time_ns: Timestamp for TASKSTATS_CMD_ATTR_PIDS command. 
> 
> Example:
> 1. Get initial snapshot with cmd_pids->time_ns=0:
>    - All tasks are returned.
>     snapshot_time = MIN(stats->time_ns) for all received taskstats
> 2. Get second snapshot with cmd_pids->time_ns = snapshot_time
>    - Only tasks that were active after "snapshot_time" are returned.

/me can only hope all this will only increase overhead for those of us
who actually use any of this..

I'm still upset over ->[us]timescaled existing, this patch set looks to
me like it will only upset me more.

  reply	other threads:[~2010-11-15 17:21 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-11 17:03 [RFC][PATCH v2 0/7] taskstats: Enhancements for precise process accounting (version 2) Michael Holzheu
2010-11-11 17:03 ` [RFC][PATCH v2 1/7] taskstats: Add new taskstats command TASKSTATS_CMD_ATTR_PIDS Michael Holzheu
2010-11-13 19:20   ` Peter Zijlstra
2010-11-15 15:53     ` Michael Holzheu
2010-11-15 16:06       ` Peter Zijlstra
2010-11-15 17:09         ` Michael Holzheu
2010-11-15 17:21           ` Peter Zijlstra [this message]
2010-11-16 12:16             ` Michael Holzheu
2010-11-16 12:36               ` Peter Zijlstra
2010-11-13 19:39   ` Peter Zijlstra
2010-11-13 20:00     ` Balbir Singh
2010-11-15 14:50     ` Michael Holzheu
2010-11-11 17:03 ` [RFC][PATCH v2 2/7] taskstats: Add "/proc/taskstats" Michael Holzheu
2010-11-11 17:03 ` [RFC][PATCH v2 3/7] taskstats: Add thread group ID to taskstats structure Michael Holzheu
2010-11-11 17:03 ` [RFC][PATCH v2 4/7] taskstats: Add per task steal time accounting Michael Holzheu
2010-11-13 19:38   ` Peter Zijlstra
2010-11-15 14:50     ` Martin Schwidefsky
2010-11-15 15:11       ` Peter Zijlstra
2010-11-15 17:42         ` Martin Schwidefsky
2010-11-15 17:45           ` Peter Zijlstra
2010-11-15 17:47           ` Peter Zijlstra
2010-11-15 17:48           ` Peter Zijlstra
2010-11-15 17:50           ` Peter Zijlstra
2010-11-15 17:59             ` Martin Schwidefsky
2010-11-15 18:08               ` Peter Zijlstra
2010-11-16  8:51                 ` Martin Schwidefsky
2010-11-16 12:16                   ` Peter Zijlstra
2010-11-16 15:33                     ` Martin Schwidefsky
2010-11-16 15:45                       ` Peter Zijlstra
2010-11-16 16:05                         ` Martin Schwidefsky
2010-11-16 18:39                           ` Jeremy Fitzhardinge
2010-11-16 16:38                         ` Avi Kivity
2010-11-16 16:43                           ` Peter Zijlstra
2010-11-16 16:56                             ` Avi Kivity
2010-11-16 17:06                               ` Avi Kivity
2010-11-11 17:03 ` [RFC][PATCH v2 5/7] taskstats: Improve cumulative CPU " Michael Holzheu
2010-11-13 18:38   ` Oleg Nesterov
2010-11-15 15:55     ` Martin Schwidefsky
2010-11-15 16:03       ` Peter Zijlstra
2010-11-15 17:49         ` Martin Schwidefsky
2010-11-15 17:51           ` Peter Zijlstra
2010-11-15 18:00             ` Martin Schwidefsky
2010-11-15 18:10               ` Peter Zijlstra
2010-11-16  8:54                 ` Martin Schwidefsky
2010-11-16 16:57     ` Michael Holzheu
2010-11-18 17:10       ` Oleg Nesterov
2010-11-19 19:46         ` Michael Holzheu
2010-11-16 17:34     ` Michael Holzheu
2010-11-16 17:50       ` Oleg Nesterov
2010-11-18 16:34       ` Oleg Nesterov
2010-11-11 17:03 ` [RFC][PATCH v2 6/7] taskstats: Fix accounting for non-leader thread exec Michael Holzheu
2010-11-11 17:11 ` [RFC][PATCH v2 7/7] taskstats: Precise process accounting user space Michael Holzheu

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=1289841705.2109.513.camel@laptop \
    --to=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=holzheu@linux.vnet.ibm.com \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nagar1234@in.ibm.com \
    --cc=oleg@redhat.com \
    --cc=roland@redhat.com \
    --cc=schwidefsky@de.ibm.com \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    --cc=venki@google.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.