From: Frank Mayhar <fmayhar@google.com>
To: Oleg Nesterov <oleg@tv-sign.ru>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
adobriyan@gmail.com, mingo@elte.hu, roland@redhat.com,
tglx@linutronix.de
Subject: Re: + itimers-fix-itimer-many-thread-hang.patch added to -mm tree
Date: Mon, 15 Sep 2008 10:49:43 -0700 [thread overview]
Message-ID: <1221500983.19012.21.camel@bobble.smo.corp.google.com> (raw)
In-Reply-To: <20080914175040.GA819@tv-sign.ru>
On Sun, 2008-09-14 at 21:50 +0400, Oleg Nesterov wrote:
> s/mm-commits/lkml/
>
> (Frank, please don't forget to CC me ;)
Did I forget last time? Oops.
> Really minor nit. Suppose that task_cputime_zero(tsk) == T and
> task_cputime_zero(sig) == F. In that case task_cputime_expired(&task_sample)
> is not needed, perhaps it makes sense to reformat this function a bit
>
> static inline int fastpath_timer_check(struct task_struct *tsk,
> struct signal_struct *sig)
> {
> if (!task_cputime_zero(&tsk->cputime_expires)) {
> struct task_cputime task_sample = {
> .utime = tsk->utime,
> .stime = tsk->stime,
> .sum_exec_runtime = tsk->se.sum_exec_runtime
> };
> if (task_cputime_expired(&task_sample, &tsk->cputime_expires))
> return 1;
> }
>
> if (!task_cputime_zero(&sig->cputime_expires)) {
> struct task_cputime group_sample;
> thread_group_cputime(tsk, &group_sample);
> if (task_cputime_expired(&group_sample, &sig->cputime_expires))
> return 1;
> }
>
> return 0;
> }
> this way it also looks more symmetrical.
Yeah, I like it better this way myself. Also...
> I'd suggest to move the "if (!sig)" check into fastpath_timer_check(),
> run_posix_cpu_timers() doesn't use sig, but this is matter a of taste.
...I agree with this. It looks better and removes the sig dereference
from run_posix_cpu_timers() where it is otherwise unused.
> This is a bit misleading, lock_task_sighand() can't fail or we have a bug.
> We already checked ->signal != NULL, and the task is current, we can use
> spin_lock(&tsk->sighand->siglock).
>
> To clarify, if lock_task_sighand() could fail, fastpath_timer_check()
> is not safe. So I'd suggest the next patch:
Okay, I get it. (This actually matches an iteration of the code but I
decided that I wasn't sure enough of my understanding to depend on
lock_task_sighand() not failing. Things have now changed enough,
though, that it makes sense again.)
> > +unsigned long long thread_group_sched_runtime(struct task_struct *p)
> > +{
> > + unsigned long flags;
> > + u64 ns;
> > + struct rq *rq;
> > + struct task_cputime totals;
> > +
> > + rq = task_rq_lock(p, &flags);
> > + thread_group_cputime(p, &totals);
> > + ns = totals.sum_exec_runtime + task_delta_exec(p, rq);
> > task_rq_unlock(rq, &flags);
>
> Hmm. This is used by cpu_clock_sample_group_locked() which has already
> called thread_group_cputime(). Yes, without task_rq_lock(), but
> thread_group_cputime() is not "atomic" anyway. And please note that
> thread_group_sched_runtime() is not that "group", we don't account
> task_delta_exec() for other threads. Perhaps we can kill this function?
> Or, at least, perhaps we can simplify this:
Deferring to your superior knowledge, I've made the suggested changes.
My original intent was to retain the original structure of the code but,
as you say, this code is now redundant.
> BTW, with or without this patch cpu_clock_sample_group() doesn't need
> ->siglock, afaics.
Fixed. I removed cpu_clock_sample_group_locked() entirely and moved the
guts of it to cpu_clock_sample_group().
I have a few more things to do; expect a new iteration of the patch
tonight or tomorrow.
--
Frank Mayhar <fmayhar@google.com>
Google, Inc.
next prev parent reply other threads:[~2008-09-15 17:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200809122353.m8CNrCmR011310@imap1.linux-foundation.org>
2008-09-14 17:50 ` Oleg Nesterov
2008-09-14 18:39 ` Ingo Molnar
2008-09-15 12:34 ` Oleg Nesterov
2008-09-15 12:56 ` Ingo Molnar
2008-09-15 17:49 ` Frank Mayhar [this message]
2008-09-16 11:13 ` Oleg Nesterov
2008-09-17 8:21 ` KAMEZAWA Hiroyuki
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=1221500983.19012.21.camel@bobble.smo.corp.google.com \
--to=fmayhar@google.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=oleg@tv-sign.ru \
--cc=roland@redhat.com \
--cc=tglx@linutronix.de \
/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
all inboxes | Powered by JetHome®