From: Peter Zijlstra <peterz@infradead.org>
To: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Venkatesh Pallipadi <venki@google.com>,
Ingo Molnar <mingo@elte.hu>, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Balbir Singh <balbir@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, Paul Turner <pjt@google.com>
Subject: Re: [PATCH 2/6] Add IRQ_TIME_ACCOUNTING, finer accounting of CPU irq time
Date: Mon, 20 Sep 2010 11:27:30 +0200 [thread overview]
Message-ID: <1284974850.2275.682.camel@laptop> (raw)
In-Reply-To: <20100920092734.3f46af9f@mschwide.boeblingen.de.ibm.com>
On Mon, 2010-09-20 at 09:27 +0200, Martin Schwidefsky wrote:
> > OK, so by virtue of calling the same function on _enter and _exit its
> > not incomplete, just weird.
>
> That is the same with CONFIG_VIRT_CPU_ACCOUNTING=y. irq_enter/irq_exit
> call account_system_vtime, the function then uses the preempt/softirq/
> hardirq counter to find out which context is currently active.
Yeah, I realized that eventually, I've so far been able to mostly ignore
all that VIRT_CPU_ACCOUNTING muck.
> > And it won't account time double, since it uses irq_start_time to
> > compute deltas between invocations and will attribute that delta to only
> > one state.
>
> irq_start_time is a bit misleading, it is a time stamp of the last update.
> The confusing part (which deserves a comment) is the fact that the delta
> is not added to anything if hardirq_count and softirq_count are zero.
Yeah, the name didn't help either, but I really expected to see two
hooks: start/exit, I did eventually figure it all out, but its a bit
daft.
If you would have had 4 hooks, the below problem would have been fixable
within the implementation.
> > You still do have the problem with local_bh_disable() though, since you
> > cannot distinguish between having bh disabled and processing softirq.
> >
> > So a hardirq that hits while you have bh disabled will inflate your
> > softirq time.
> >
> > A possible solution is to have local_bh_{disable,enable} {add,sub}
> > 2*SOFTIRQ_OFFSET and have the processing use SOFTIRQ_OFFSET, will need a
> > bit of a code shuffle though.
>
> Hmm, that bug is valid for CONFIG_VIRT_CPU_ACCOUNTING=y as well.
And nobody ever noticed?
next prev parent reply other threads:[~2010-09-20 9:27 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-17 1:56 [PATCH 0/6] Proper kernel irq time accounting Venkatesh Pallipadi
2010-09-17 1:56 ` [PATCH 1/6] Consolidate account_system_vtime extern declaration Venkatesh Pallipadi
2010-09-17 1:56 ` [PATCH 2/6] Add IRQ_TIME_ACCOUNTING, finer accounting of CPU irq time Venkatesh Pallipadi
2010-09-19 11:11 ` Peter Zijlstra
2010-09-20 17:13 ` Venkatesh Pallipadi
2010-09-20 17:23 ` Peter Zijlstra
2010-09-19 11:21 ` Peter Zijlstra
2010-09-19 11:42 ` Peter Zijlstra
2010-09-19 12:01 ` Peter Zijlstra
2010-09-20 7:27 ` Martin Schwidefsky
2010-09-20 9:27 ` Peter Zijlstra [this message]
2010-09-20 17:16 ` Venkatesh Pallipadi
2010-09-20 17:26 ` Peter Zijlstra
2010-09-27 20:35 ` [PATCH] si time accounting accounts bh_disable'd time to si Venkatesh Pallipadi
2010-09-27 20:53 ` Eric Dumazet
2010-09-27 21:11 ` Venkatesh Pallipadi
2010-09-27 21:16 ` Eric Dumazet
2010-09-30 11:17 ` Peter Zijlstra
2010-09-17 1:56 ` [PATCH 3/6] x86: Add IRQ_TIME_ACCOUNTING in x86 Venkatesh Pallipadi
2010-09-17 1:56 ` [PATCH 4/6] sched: Do not account irq time to current task Venkatesh Pallipadi
2010-09-19 11:28 ` Peter Zijlstra
2010-09-20 17:33 ` Venkatesh Pallipadi
2010-09-20 17:38 ` Peter Zijlstra
2010-09-20 17:40 ` Venkatesh Pallipadi
2010-09-17 1:56 ` [PATCH 5/6] sched: Remove irq time from available CPU power Venkatesh Pallipadi
2010-09-19 11:31 ` Peter Zijlstra
2010-09-20 17:38 ` Venkatesh Pallipadi
2010-09-17 1:56 ` [PATCH 6/6] Export per cpu hardirq and softirq time in proc Venkatesh Pallipadi
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=1284974850.2275.682.camel@laptop \
--to=peterz@infradead.org \
--cc=balbir@linux.vnet.ibm.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=pjt@google.com \
--cc=schwidefsky@de.ibm.com \
--cc=tglx@linutronix.de \
--cc=venki@google.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