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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 2C9D9C433DF for ; Sun, 18 Oct 2020 00:56:54 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A70A020E65 for ; Sun, 18 Oct 2020 00:56:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="isYgrI/I" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A70A020E65 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=telegraphics.com.au Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:Message-ID:In-Reply-To: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=UIQjskhCWCaLBGbP3/whv+kLXeKIeNMlDEsgUk7iU7c=; b=isYgrI/I4HBwH9Co9ErCT0vy+ sN+v59xDotBq7QxM67NEXimVQpQKQ0PQWSIPH+RmhK1ZbxJTvK9hNnUAd4a7NHj3YonP5o2ysY3lS +pLIxuYB/VcLOfsj2p8kfcDRyXmH1mozWF8KRcr0xsaShgglXYDwX9GFVubTnoZ3zWEZenKI0ek4r kCPLmavfRbyWsR9vlZhCBz3ejvZ+vylwk0+K74ucUCh8xL7fcvs2YLYQ15EQVi2JSFSzj1Tw5gZqH bPiMC72CleAW2pb5LaIY+9LmMHmkziA0bjATY6uOwq/xO2FVTxzTdPOB2vUAMO/z4dlZyi/PpBaEj 2QtSp53Kg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kTwyi-0002UV-SD; Sun, 18 Oct 2020 00:55:16 +0000 Received: from kvm5.telegraphics.com.au ([98.124.60.144]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kTwyg-0002U6-6D for linux-arm-kernel@lists.infradead.org; Sun, 18 Oct 2020 00:55:15 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id C51E82A7EE; Sat, 17 Oct 2020 20:55:06 -0400 (EDT) Date: Sun, 18 Oct 2020 11:54:54 +1100 (AEDT) From: Finn Thain To: Arnd Bergmann Subject: Re: [RFC 13/13] m68k: mac: convert to generic clockevent In-Reply-To: Message-ID: References: <20201008154651.1901126-1-arnd@arndb.de> <20201008154651.1901126-14-arnd@arndb.de> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201017_205514_243391_2C998E66 X-CRM114-Status: GOOD ( 34.12 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Sam Creasey , Fenghua Yu , Linus Walleij , Tony Luck , Thomas Gleixner , Parisc List , linux-ia64@vger.kernel.org, Stephen Boyd , Helge Deller , Daniel Lezcano , "linux-kernel@vger.kernel.org" , Russell King , "James E.J. Bottomley" , linux-m68k , Geert Uytterhoeven , Linux ARM , John Stultz , Philip Blundell , Greg Ungerer , Joshua Thompson Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 15 Oct 2020, Arnd Bergmann wrote: > On Thu, Oct 15, 2020 at 3:19 AM Finn Thain wrote: > > > > On Sat, 10 Oct 2020, Arnd Bergmann wrote: > > > > > > Perhaps patch 13 does not belong in this series (?). > > > > > > > > All m68k platforms will need conversion before the TODO can be removed > > > > from Documentation/features/time/clockevents/arch-support.txt. > > > > > > Yes, correct. I marked this patch as RFC instead of PATCH, as I'm just > > > trying to find out where it should be headed. I would hope the other > > > patches can just get merged. > > > > > > > I wonder whether we can improve support for your proposed configuration > > i.e. a system with no oneshot clockevent device. > > > > The 16 platforms you identified are not all in that category but I suspect > > that there are others which are (though they don't appear in this series > > because they already use GENERIC_CLOCKEVENTS). > > > > One useful optimization would be some way to elide oneshot clockevent > > support (perhaps with the help of Link Time Optimization). > > I think this already happens if one picks CONFIG_HZ_PERIODIC while > disabling HIGH_RES_TIMERS. In that case, CONFIG_TICK_ONESHOT > remains disabled. > That configuration still produces the same 5 KiB of bloat. I see that kernel/time/Kconfig has this -- # Core internal switch. Selected by NO_HZ_COMMON / HIGH_RES_TIMERS. This is # only related to the tick functionality. Oneshot clockevent devices # are supported independent of this. config TICK_ONESHOT bool But my question was really about both kinds of dead code (oneshot device support and oneshot tick support). Anyway, after playing with the code for a bit I don't see any easy way to reduce the growth in text size. > ... > > After looking at the chip documentation I don't think it's viable to > > use the hardware timers in the way I proposed. A VIA register access > > requires at least one full VIA clock cycle (about 1.3 us) which means > > register accesses themselves cause timing delays. They also make > > clocksource reads expensive. > > > > I think this rules out oneshot clockevent devices because if the > > system offered such a device it would preferentially get used as a > > tick device. > > > > So I think your approach (periodic clockevent device driven by the > > existing periodic tick interrupt) is best for this platform due to > > simplicity (not much code) and performance (good accuracy, no > > additional overhead). > > Yes, makes sense. I think the one remaining problem with the periodic > mode in this driver is that it can drop timer ticks when interrupts are > disabled for too long, while in oneshot mode there may be a way to know > how much time has passed since the last tick as long as the counter does > not overflow. Is there any benefit from adopting a oneshot tick (rather than periodic) if no clocksource is consulted when calculating the next interval? (I'm assuming NO_HZ is not in use, for reasons discussed below.) > I would agree that despite this oneshot mode is probably worse overall > for timekeeping if the register accesses introduce systematic errors. > It probably has to be tried. But consulting a VIA clocksource on every tick would be expensive on this platform, so if that was the only way to avoid cumulative errors, I'd probably just stick with the periodic tick. > ... > The arm/rpc timer seems to be roughly in the same category as most of > the m68k ones or the i8253 counter on a PC. It's possible that some of > them could use the same logic as drivers/clocksource/i8253.o as long as > there is any hardware oneshot mode. > There appear to be 15 platforms in that category. 4 have no clocksource besides the jiffies clocksource, meaning there's no practical alternative to using a periodic tick, like you did in your RFC patch: arch/m68k/apollo/config.c arch/m68k/q40/q40ints.c arch/m68k/sun3/sun3ints.c arch/m68k/sun3x/time.c The other 11 platforms in that category also have 'synthetic' clocksources derived from a timer reload interrupt. In 3 cases, the clocksource read method does not (or can not) check for a pending counter reload interrupt. For these also, I see no practical alternative to the approach you've taken in your RFC patch: arch/m68k/68000/timers.c arch/m68k/atari/time.c arch/m68k/coldfire/timers.c That leaves 8 platforms that have reliable clocksource devices which should be able to provide an accurate reading even in the presence of a dropped tick (due to drivers disabling interrupts for too long): arch/arm/mach-rpc/time.c arch/m68k/amiga/config.c arch/m68k/bvme6000/config.c arch/m68k/coldfire/sltimers.c arch/m68k/hp300/time.c arch/m68k/mac/via.c arch/m68k/mvme147/config.c arch/m68k/mvme16x/config.c But is there any reason to adopt a oneshot tick on any of these platforms, if NO_HZ won't eliminate the timer interrupt that's needed to run a 'synthetic' clocksource? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel