lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 26 Nov 2012 14:33:43 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 2/3] cputime: Rename thread_group_times to
 thread_group_cputime_adjusted

On Mon, 2012-11-26 at 20:24 +0100, Frederic Weisbecker wrote:
> 2012/11/26 Steven Rostedt <rostedt@...dmis.org>:
> > On Fri, 2012-11-23 at 15:21 +0100, Frederic Weisbecker wrote:
> >> We have thread_group_cputime() and thread_group_times(). The naming
> >> doesn't provide enough information about the difference between
> >> these two APIs.
> >>
> >> To lower the confusion, rename thread_group_times() to
> >> thread_group_cputime_adjusted(). This name better suggests that
> >> it's a version of thread_group_cputime() that does some stabilization
> >> on the raw cputime values. ie here: scale on top of CFS runtime
> >> stats and bound lower value for monotonicity.
> >
> > But, thread_group_times() does not do any type of adjustment. It only
> > retrieves the cpu times:
> >
> > void thread_group_times(struct task_struct *p, cputime_t *ut, cputime_t *st)
> > {
> >         struct task_cputime cputime;
> >
> >         thread_group_cputime(p, &cputime);
> >
> >         *ut = cputime.utime;
> >         *st = cputime.stime;
> > }
> 
> This is the CONFIG_VIRT_CPU_ACCOUNTING only version. It also needs
> some monotonicity guard IMO but that's another issue.
> But please look at the other version.

Yeah, I just noticed. That turkey juice is still having an affect on
me ;-)

> 
> > It retrieves the current times, it doesn't adjust them.
> >
> > I'm thinking the current name is more accurate.

OK, let's take a look at the other version now:

void thread_group_times(struct task_struct *p, cputime_t *ut, cputime_t *st)
{
        struct signal_struct *sig = p->signal;
        struct task_cputime cputime;
        cputime_t rtime, utime, total;

        thread_group_cputime(p, &cputime);

        total = cputime.utime + cputime.stime;
        rtime = nsecs_to_cputime(cputime.sum_exec_runtime);

        if (total)
                utime = scale_utime(cputime.utime, rtime, total);
        else
                utime = rtime;

        sig->prev_utime = max(sig->prev_utime, utime);
        sig->prev_stime = max(sig->prev_stime, rtime - sig->prev_utime);

        *ut = sig->prev_utime;
        *st = sig->prev_stime;
}

So this version also updates the task's signal->prev_[us]times as well. 

I guess I'll wait for you to explain to me more about what is going
on :-)

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ