All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jay Lan <jlan@sgi.com>
To: Shailabh Nagar <nagar@watson.ibm.com>
Cc: Andrew Morton <akpm@osdl.org>, Jay Lan <jlan@engr.sgi.com>,
	linux-kernel@vger.kernel.org, balbir@in.ibm.com, jes@sgi.com,
	csturtiv@sgi.com, tee@sgi.com, guillaume.thouvenin@bull.net
Subject: Re: [patch 1/3] basic accounting over taskstats
Date: Thu, 03 Aug 2006 11:48:32 -0700	[thread overview]
Message-ID: <44D24500.7060107@sgi.com> (raw)
In-Reply-To: <44D20079.2000601@watson.ibm.com>

Shailabh Nagar wrote:
> Andrew Morton wrote:
> 
>>
>> Or we remove this field altogether, perhaps.  The same info is available
>> from /proc/pid/stat anyway.  Is it really needed?
>>
> 
> Gathering this data in userspace from /proc might be
> difficult esp. for short-lived tasks.

This is a serious concern. I think increasing TS_COMM_LEN
to 32 would be a good solution.

> 
> Also, /proc may not be mounted ? I'd heard somewhere that
> some sysadmins don't install /proc for security reasons.
> Don't know how far thats true.
> 
> Several other fields, totalling 58 bytes, added by the CSA
> patches are also duplicated in /proc/pid/stat. But all of them
> could change in value during the lifetime of a task so I'm
> guessing its not useful to get them from /proc
> even if some kind of userspace polling of the value was
> possible.

The same concern above applies to here, doesn't it?

Regards,
  - jay


> 
> But if there is a way, it would sure save a lot of payload
> sent over taskstats !
> 
> "duplicate" fields from CSA:
> +    __u8    ac_nice;        /* task_nice */
> +    char    ac_comm[TS_COMM_LEN];    /* Command name */
> +    __u8    ac_sched;        /* Scheduling discipline */
> +    __u32    ac_pid;            /* Process ID */
> +    __u32    ac_ppid;        /* Parent process ID */
> +    __u64    ac_utime;        /* User CPU time [usec] */
> +    __u64    ac_stime;        /* SYstem CPU time [usec] */
> +    __u64    ac_minflt;        /* Minor Page Fault */
> +    __u64    ac_majflt;        /* Major Page Fault */


  reply	other threads:[~2006-08-03 18:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-03  4:20 [patch 1/3] basic accounting over taskstats Jay Lan
2006-08-03  6:52 ` Andrew Morton
2006-08-03 13:56   ` Shailabh Nagar
2006-08-03 18:48     ` Jay Lan [this message]
2006-08-03 19:29       ` Shailabh Nagar

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=44D24500.7060107@sgi.com \
    --to=jlan@sgi.com \
    --cc=akpm@osdl.org \
    --cc=balbir@in.ibm.com \
    --cc=csturtiv@sgi.com \
    --cc=guillaume.thouvenin@bull.net \
    --cc=jes@sgi.com \
    --cc=jlan@engr.sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nagar@watson.ibm.com \
    --cc=tee@sgi.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.