All of lore.kernel.org
 help / color / mirror / Atom feed
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?

  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 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.