From: Rik van Riel <riel@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, mingo@kernel.org,
pbonzini@redhat.com, fweisbec@gmail.com, wanpeng.li@hotmail.com,
efault@gmx.de, tglx@linutronix.de, rkrcmar@redhat.com
Subject: Re: [PATCH 5/5] irqtime: drop local_irq_save/restore from irqtime_account_irq
Date: Wed, 22 Jun 2016 17:55:19 -0400 [thread overview]
Message-ID: <1466632519.15275.29.camel@redhat.com> (raw)
In-Reply-To: <20160621214934.GT30909@twins.programming.kicks-ass.net>
[-- Attachment #1: Type: text/plain, Size: 1918 bytes --]
On Tue, 2016-06-21 at 23:49 +0200, Peter Zijlstra wrote:
> On Thu, Jun 16, 2016 at 12:06:07PM -0400, riel@redhat.com wrote:
> >
> > @@ -53,36 +56,72 @@ DEFINE_PER_CPU(seqcount_t, irq_time_seq);
> > * softirq -> hardirq, hardirq -> softirq
> > *
> > * When exiting hardirq or softirq time, account the elapsed time.
> > + *
> > + * When exiting softirq time, subtract the amount of hardirq time
> > that
> > + * interrupted this softirq run, to avoid double accounting of
> > that time.
> > */
> > void irqtime_account_irq(struct task_struct *curr, int irqtype)
> > {
> > + u64 prev_softirq_start;
> > + u64 prev_hardirq;
> > + u64 hardirq_time;
> > + s64 delta = 0;
> We appear to always assign to delta, so this initialization seems
> superfluous.
It gets rid of a compiler warning, since gcc is not
smart enough to know that the result of in_softirq()
will be the same throughout the function.
Using a bool leaving_softirq = in_softirq() also
gets rid of the warning, and makes the function a
little more readable, so I am doing that.
> > + if (irqtype == HARDIRQ_OFFSET) {
> > + delta = sched_clock_cpu(cpu) -
> > __this_cpu_read(hardirq_start_time);
> > + __this_cpu_add(hardirq_start_time, delta);
> > + } else do {
> > + u64 now = sched_clock_cpu(cpu);
> > + hardirq_time = READ_ONCE(per_cpu(cpu_hardirq_time,
> > cpu));
> Which makes this per_cpu(,cpu) usage somewhat curious. What's wrong
> with
> __this_cpu_read() ?
I played around with it a bit, and it seems that
__this_cpu_read does not want to nest inside
READ_ONCE. Nobody else seems to be doing that,
either.
Back to READ_ONCE(per_cpu(,cpu)) it is...
> Maybe split the whole thing on irqtype at the very start, instead of
> the
> endless repeated branches?
I untangled the whole thing in the next version,
which I will post after testing.
--
All rights reversed
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2016-06-22 21:55 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-16 16:06 [PATCH 0/5] sched,time: fix irq time accounting with nohz_idle riel
2016-06-16 16:06 ` [PATCH 1/5] sched,time: count actually elapsed irq & softirq time riel
2016-06-16 16:22 ` kbuild test robot
2016-06-21 21:21 ` Peter Zijlstra
2016-06-21 22:20 ` Rik van Riel
2016-06-22 10:40 ` Paolo Bonzini
2016-06-22 10:52 ` Peter Zijlstra
2016-06-16 16:06 ` [PATCH 2/5] nohz,cputime: remove VTIME_GEN vtime irq time code riel
2016-06-16 16:06 ` [PATCH 3/5] cputime: allow irq time accounting to be selected as an option riel
2016-06-16 16:06 ` [PATCH 4/5] irqtime: add irq type parameter to irqtime_account_irq riel
2016-06-16 16:06 ` [PATCH 5/5] irqtime: drop local_irq_save/restore from irqtime_account_irq riel
2016-06-21 21:49 ` Peter Zijlstra
2016-06-21 22:23 ` Rik van Riel
2016-06-21 22:28 ` Peter Zijlstra
2016-06-21 22:32 ` Rik van Riel
2016-06-22 21:55 ` Rik van Riel [this message]
2016-06-23 13:52 ` Paolo Bonzini
2016-06-23 15:24 ` Rik van Riel
-- strict thread matches above, loose matches on Subject: below --
2016-06-23 2:25 [PATCH v2 0/5] sched,time: fix irq time accounting with nohz_idle riel
2016-06-23 2:25 ` [PATCH 5/5] irqtime: drop local_irq_save/restore from irqtime_account_irq riel
2016-06-08 2:29 [PATCH RFC 0/5] sched,time: make irq time accounting work for nohz_idle riel
2016-06-08 2:30 ` [PATCH 5/5] irqtime: drop local_irq_save/restore from irqtime_account_irq riel
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=1466632519.15275.29.camel@redhat.com \
--to=riel@redhat.com \
--cc=efault@gmx.de \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rkrcmar@redhat.com \
--cc=tglx@linutronix.de \
--cc=wanpeng.li@hotmail.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.