lkml.org 
[lkml]   [2020]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject[RFC PATCH 0/4] irq: Reorder time handling against HARDIRQ_OFFSET on IRQ entry
Date
There are two issues with the current layout of tick_irq_enter() as
it's called before HARDIRQ_OFFSET is incremented:

1) It's not correctly handled by lockdep which doesn't consider it as
hardirq context. And jiffies/timekeeping update take a few interesting
locks.

2) Softirqs need to be explicitly disabled around it to prevent ksoftirqd
from being spuriously woken up.

The current call dependency prevents tick_irq_enter() from being moved
after HARDIRQ_OFFSET: account_irq_enter_time() needs to be called before
HARDIRQ_OFFSET incrementation due to cputime index dispatch and it must
be called after tick_irq_enter() which updates the clocks that may be
necessary for cputime accounting.

Here is a proposal to fix this layout.

(The EXPORT_SYMBOL_GPL() in vtime will likely disappear in the next take
as they don't seem to be necessary anymore, but I'll need to check
that thoroughly).

git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
irq/core

HEAD: 9502ee20aed8bb847176e1d7d83ccd0625430744


Frederic Weisbecker (4):
sched/vtime: Consolidate IRQ time accounting
s390/vtime: Convert to consolidated IRQ time accounting
irqtime: Move irqtime entry accounting after irq offset incrementation
irq: Call tick_irq_enter() inside HARDIRQ_OFFSET

arch/ia64/kernel/time.c | 22 +++++++---
arch/powerpc/kernel/time.c | 60 ++++++++++++++++++++--------
arch/s390/include/asm/vtime.h | 1 -
arch/s390/kernel/vtime.c | 60 ++++++++++++++++++----------
include/linux/hardirq.h | 4 +-
include/linux/vtime.h | 18 ++++-----
kernel/sched/cputime.c | 75 +++++++++++++++++++++++++++--------
kernel/softirq.c | 16 +++-----
8 files changed, 176 insertions(+), 80 deletions(-)

--
2.25.1

\
 
 \ /
  Last update: 2020-11-25 03:18    [W:0.037 / U:0.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site