From: Jay Lan <jlan@sgi.com>
To: balbir@in.ibm.com
Cc: Andrew Morton <akpm@osdl.org>,
lkml <linux-kernel@vger.kernel.org>,
Shailabh Nagar <nagar@watson.ibm.com>, Jes Sorensen <jes@sgi.com>,
Chris Sturtivant <csturtiv@sgi.com>, Tony Ernst <tee@sgi.com>
Subject: Re: [patch 1/3] add basic accounting fields to taskstats
Date: Tue, 01 Aug 2006 14:51:32 -0700 [thread overview]
Message-ID: <44CFCCE4.7060702@sgi.com> (raw)
In-Reply-To: <44CF6433.50108@in.ibm.com>
Balbir Singh wrote:
> Jay Lan wrote:
>
>>
>> -#define TASKSTATS_VERSION 1
>> +#define TASKSTATS_VERSION 2
>> +#define TASK_COMM_LEN 16
>>
>
>
> We should find a way to keep this in sync with with the definition
> in linux/sched.h (won't we a warning if both this header and
> linux/sched.h are included together?)
I do not know how to sync it up. This header linux/taskstats.h is
meant to be included by userspace programs. If an application
happens to include linux/sched.h, which includes linux/time.h,
the application will very likely have compilation errors because
the "struct timespec" declaration in <linux/time.h> and <time.h>
are conflicting.
The <linux/acct.h> defines it to
#define ACCT_COMM 16
I can change our define to TS_COMM_LEN with remakes saying it
should be in sync with the TAKS_COMM_LEN defined in linux/sched.h.
If there is a better way, i am eager to know it.
>
>
>
>> + * fill in basic accounting fields
>> + */
>> +static void bacct_add_tsk(struct taskstats *stats, struct task_struct
>> *tsk)
>> +{
>> + u64 run_time;
>> + struct timespec uptime;
>> +
>> + /* calculate run_time in nsec */
>> + do_posix_clock_monotonic_gettime(&uptime);
>> + run_time = (u64)uptime.tv_sec*NSEC_PER_SEC + uptime.tv_nsec;
>> + run_time -= (u64)current->group_leader->start_time.tv_sec *
>> NSEC_PER_SEC
>> + + current->group_leader->start_time.tv_nsec;
>> + do_div(run_time, NSEC_PER_USEC); /* rebase run_time to usec */
>> + stats->ac_etime = run_time;
>> + do_div(run_time, USEC_PER_SEC); /* rebase run_time to sec */
>> + stats->ac_btime = xtime.tv_sec - run_time;
>> + if (thread_group_leader(tsk)) {
>> + stats->ac_exitcode = tsk->exit_code;
>> + if (tsk->flags & PF_FORKNOEXEC)
>> + stats->ac_flag |= AFORK;
>> + }
>> + if (tsk->flags & PF_SUPERPRIV)
>> + stats->ac_flag |= ASU;
>> + if (tsk->flags & PF_DUMPCORE)
>> + stats->ac_flag |= ACORE;
>> + if (tsk->flags & PF_SIGNALED)
>> + stats->ac_flag |= AXSIG;
>> + stats->ac_nice = task_nice(tsk);
>> + stats->ac_sched = tsk->policy;
>> + stats->ac_uid = tsk->uid;
>> + stats->ac_gid = tsk->gid;
>> + stats->ac_pid = tsk->pid;
>> + stats->ac_ppid = (tsk->parent) ? tsk->parent->pid : 0;
>> + stats->ac_utime = tsk->utime * USEC_PER_TICK;
>> + stats->ac_stime = tsk->stime * USEC_PER_TICK;
>
>
> I think you should use the portable cputime_xxxx() API since
> tsk->utime and tsk->stime are of type cputime_t
Will fix it.
>
>
>> + /* Each process gets a minimum of a half tick cpu time */
>> + if ((stats->ac_utime == 0) && (stats->ac_stime == 0)) {
>> + stats->ac_stime = USEC_PER_TICK/2;
>> + }
>> +
>
>
> This is confusing. Half tick does not make any sense from the
> scheduler view point (or am I missing something?), so why
> return half a tick to the user.
It must be inherited from old code dated back to Cray UNICOS.
I do not know if bad thing can happen if both utime and stime
are less than 1 usec... I guess not. But i agree that
half a tick does not make sense. To play safe, we can change
it to 1 usec if both utime and stime are sub microsecond.
What do you think?
Thanks,
- jay
>
>
next prev parent reply other threads:[~2006-08-01 21:51 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-31 19:20 Jay Lan
2006-07-31 20:23 ` Shailabh Nagar
2006-07-31 21:50 ` Jay Lan
2006-08-01 14:24 ` Balbir Singh
2006-08-01 21:51 ` Jay Lan [this message]
2006-08-02 15:31 ` Shailabh Nagar
2006-08-02 17:17 ` Balbir Singh
2006-08-02 17:37 ` Shailabh Nagar
2006-08-02 21:09 ` Andrew Morton
2006-08-02 23:47 ` Jay Lan
2006-08-03 3:02 ` Balbir Singh
2006-08-07 21:23 ` Jay Lan
2006-08-08 5:22 ` Balbir Singh
2006-08-08 16:40 ` Jay Lan
2006-08-08 14:57 Al Boldi
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=44CFCCE4.7060702@sgi.com \
--to=jlan@sgi.com \
--cc=akpm@osdl.org \
--cc=balbir@in.ibm.com \
--cc=csturtiv@sgi.com \
--cc=jes@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome