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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox