public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: menage@google.com, dev@sw.ru, xemul@sw.ru, serue@us.ibm.com,
	vatsa@in.ibm.com, ebiederm@xmission.com, haveblue@us.ibm.com,
	svaidy@linux.vnet.ibm.com, balbir@in.ibm.com, pj@sgi.com,
	cpw@sgi.com, ckrm-tech@lists.sourceforge.net,
	linux-kernel@vger.kernel.org, containers@lists.osdl.org,
	mbligh@google.com, rohitseth@google.com, devel@openvz.org
Subject: Re: Per container statistics (containerstats)
Date: Fri, 08 Jun 2007 07:51:12 +0530	[thread overview]
Message-ID: <4668BD18.7090603@linux.vnet.ibm.com> (raw)
In-Reply-To: <20070607155445.edd5fded.akpm@linux-foundation.org>

Andrew Morton wrote:
> 
> I'd have hoped to see containerstats.c in here.
> 

The current statistics code is really small, so it fit into taskstats.c.
May be in the future, we could re-factor it and move it out.

>> +#ifndef _LINUX_CONTAINERSTATS_H
>> +#define _LINUX_CONTAINERSTATS_H
>> +
>> +#include <linux/taskstats.h>
> 
> I don't understand the relationship between containerstats and taskstats. 
> afacit it's using the same genetlink channel?
> 

I've registered containerstats_ops with the same family as taskstats to
reuse the taskstats interface.

>> +enum {
>> +	CONTAINERSTATS_CMD_UNSPEC = __TASKSTATS_CMD_MAX,	/* Reserved */
> 
> This seems to mean that the containerstats commands all get renumbered if
> we add new taskstats commands.  That would be bad?
> 

As per comment above, since we register containerstats_ops with the taskstats
family, the commands need to be unique, hence we start where taskstats ended
(left off)

>> + */
>> +int containerstats_build(struct containerstats *stats, struct dentry *dentry)
>> +{
>> +	int ret = -EINVAL;
>> +	struct task_struct *g, *p;
>> +	struct container *cont, *root_cont;
>> +	struct container *src_cont;
>> +	int subsys_id;
>> +	struct containerfs_root *root;
>> +
>> +	/*
>> +	 * Validate dentry by checking the superblock operations
>> +	 */
>> +	if (dentry->d_sb->s_op != &container_ops)
>> +		 goto err;
>> +
>> +	ret = 0;
>> +	src_cont = (struct container *)dentry->d_fsdata;
> 
> Unneeded cast.
> 

Will remove

>> +	rcu_read_lock();
>> +
>> +	for_each_root(root) {
>> +		if (!root->subsys_bits)
>> +			continue;
>> +		root_cont = &root->top_container;
>> +		get_first_subsys(root_cont, NULL, &subsys_id);
>> +		do_each_thread(g, p) {
> 
> this needs tasklist_lock?
> 

rcu_read_lock() should be fine. From Eric's patch at

2.6.17-mm2 - proc-remove-tasklist_lock-from-proc_pid_readdir.patch

The patch mentions that "We don't need the tasklist_lock to safely
iterate through processes anymore."

>> +			cont = task_container(p, subsys_id);
>> +			if (cont == src_cont) {
>> +				switch (p->state) {
>> +				case TASK_RUNNING:
>> +					stats->nr_running++;
>> +					break;
>> +				case TASK_INTERRUPTIBLE:
>> +					stats->nr_sleeping++;
>> +					break;
>> +				case TASK_UNINTERRUPTIBLE:
>> +					stats->nr_uninterruptible++;
>> +					break;
>> +				case TASK_STOPPED:
>> +					stats->nr_stopped++;
>> +					break;
>> +				default:
>> +					if (delayacct_is_task_waiting_on_io(p))
>> +						stats->nr_io_wait++;
>> +					break;
>> +				}
>> +			}
>> +		} while_each_thread(g, p);
>> +	}
>> +	rcu_read_unlock();
>> +err:
>> +	return ret;
>> +}
>> +
>>  static int cmppid(const void *a, const void *b)
>>  {
>>  	return *(pid_t *)a - *(pid_t *)b;
>> diff -puN kernel/sched.c~containers-taskstats kernel/sched.c
>> --- linux-2.6.22-rc2-mm1/kernel/sched.c~containers-taskstats	2007-06-05 17:21:57.000000000 +0530
>> +++ linux-2.6.22-rc2-mm1-balbir/kernel/sched.c	2007-06-05 17:21:57.000000000 +0530
>> @@ -4280,11 +4280,13 @@ void __sched io_schedule(void)
>>  {
>>  	struct rq *rq = &__raw_get_cpu_var(runqueues);
>>  
>> +	delayacct_set_flag(DELAYACCT_PF_BLKIO);
>>  	delayacct_blkio_start();
> 
> Would it be suitable and appropriate to embed the delayacct_set_flag() call
> inside delayacct_blkio_start()?
> 

Yes, I should have done that, will do.


-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL

  reply	other threads:[~2007-06-08  2:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-06 11:58 Per container statistics (containerstats) Balbir Singh
2007-06-07 22:54 ` Andrew Morton
2007-06-08  2:21   ` Balbir Singh [this message]
2007-06-08  2:28     ` Paul Menage
2007-06-08  2:39     ` Andrew Morton
2007-06-08  2:44       ` Balbir Singh
2007-06-08 10:50     ` [ckrm-tech] " Balbir Singh
2007-06-08 10:57       ` Balbir Singh

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=4668BD18.7090603@linux.vnet.ibm.com \
    --to=balbir@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=balbir@in.ibm.com \
    --cc=ckrm-tech@lists.sourceforge.net \
    --cc=containers@lists.osdl.org \
    --cc=cpw@sgi.com \
    --cc=dev@sw.ru \
    --cc=devel@openvz.org \
    --cc=ebiederm@xmission.com \
    --cc=haveblue@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@google.com \
    --cc=menage@google.com \
    --cc=pj@sgi.com \
    --cc=rohitseth@google.com \
    --cc=serue@us.ibm.com \
    --cc=svaidy@linux.vnet.ibm.com \
    --cc=vatsa@in.ibm.com \
    --cc=xemul@sw.ru \
    /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