From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 39503C2D0E4 for ; Wed, 25 Nov 2020 02:16:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CDD2620BED for ; Wed, 25 Nov 2020 02:16:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="tuzw5s5E" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726326AbgKYCPs (ORCPT ); Tue, 24 Nov 2020 21:15:48 -0500 Received: from mail.kernel.org ([198.145.29.99]:38062 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726124AbgKYCPs (ORCPT ); Tue, 24 Nov 2020 21:15:48 -0500 Received: from localhost.localdomain (unknown [94.238.200.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7A0B32075A; Wed, 25 Nov 2020 02:15:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1606270548; bh=K3URZ8EWQ5J0esRj2c+St3iSMo4ccLVWar922WMeUC4=; h=From:To:Cc:Subject:Date:From; b=tuzw5s5EENva+wz5up3kqkjaVshLtl7duQYJ97eDWDdvdP9JnsQQ2Ka33i4Ur3pFM UyX6BwQxp2WhTms8sH9gCvZRNJI0JcxjpH1FI0CcMAcdHz3QuFARhD5fVeA5frz6Xv w/Ou7knK2OiqyBWqw6dvSxCYPxP3vSwtKUASL7pw= From: Frederic Weisbecker To: Thomas Gleixner Cc: LKML , Frederic Weisbecker , Tony Luck , Peter Zijlstra , Vasily Gorbik , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , Christian Borntraeger , Fenghua Yu , Heiko Carstens Subject: [RFC PATCH 0/4] irq: Reorder time handling against HARDIRQ_OFFSET on IRQ entry Date: Wed, 25 Nov 2020 03:15:38 +0100 Message-Id: <20201125021542.30237-1-frederic@kernel.org> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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