Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp4622628pxu; Tue, 13 Oct 2020 03:07:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw68zgZrfB16WTEdfmt1I9Vf11sLyJqRaSHr7zc8PaXYuy6xR89BXUx39RmGae7owE2L9ll X-Received: by 2002:a17:906:24cd:: with SMTP id f13mr30945743ejb.329.1602583671495; Tue, 13 Oct 2020 03:07:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602583671; cv=none; d=google.com; s=arc-20160816; b=cldfgz9Q61swRzmYmOYfwIUzVySmut0XNuSnQJYubYJMonJsQ5q8G3P9Q6PuQgey+z okSJnmmZnEMXJBcZunD0/FLqQI5CklWGUzxQ3isOCVttVUU3vsmmnhamBDvrNE0+IbHx Or0Wz46y1KsK6ID7iuFsQ32YEmjNV/MVLhyNwhO2pAIv6B6zQZdZv959PtYMK0eNvErc 1IN9w/E42NAFfqkMgpQkMiiiQCf2qTSEdCu9Ni34yo7+cG7sd08NwUmZu1U8u+HyV+3z kYiIe0w/tWsHEHakiH+F8zBi8EkepGCizQprSUW0AWtBZUgcGwuR8GK3r12pFvVPQ2ug AsHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=2D9ftb4BNlPgU4fGOVcc9hqHah5NjLimpJgfMw28f+o=; b=CGTq1bbCwm7tPKxX5LxlAqGr3VlLjK+X15fEGVKTgjLig37JmbRFf0GgOHDsATaZ9U IxCsBogU6wHw4e8QwA2r+/tO535YohmOzxnbUUxTwlZVW4ifjt5RjwcoIYbXlqQqANeV vpibzF6AECRmMg44BXRSntyPsgavEp0TBYJDldGJAp3OV1iTrHGMdd4tgFnZtOcHsDQW 5yjkbjQm+1OAfmFuhg9bDSVyNg0t5bczt+jozIAomVN9EAU97sHr9gsp/cZjizIhQv4U je5K47cPnS1QTxZ5HcmgfonX24BVK1UvKwQz29ingYIt8YSDPv68c4PnYPMw1e1bvUvd ZLGw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b="3/o7m4+J"; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bz23si13582236ejc.703.2020.10.13.03.07.26; Tue, 13 Oct 2020 03:07:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b="3/o7m4+J"; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729436AbgJLUoj (ORCPT + 99 others); Mon, 12 Oct 2020 16:44:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40560 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729162AbgJLUoj (ORCPT ); Mon, 12 Oct 2020 16:44:39 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F0312C0613D0; Mon, 12 Oct 2020 13:44:38 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1602535477; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2D9ftb4BNlPgU4fGOVcc9hqHah5NjLimpJgfMw28f+o=; b=3/o7m4+JNTO8cP79WuCRiuRnkNMsIzvD57ZEvEm9wyGyPse3QVqeClMl/XBroA5Gw5sryY yt1B4FPqa8dQZVnOskzF4aK2RvAdaPtSNuvrq2kiHKwjtrI2O56Doey5MrVWZ1PmMtFe51 nIgCRI/OA1S/wFNBCKjgyh2PPtOYor7ZlBPcXGGO9efhAqy/xfK5oMj09dFsWK+REE51vs QtnliaSEueOg5DKUKyvIr/bYO3yvxWZ6lOX7iWnhT5LL+Vf3dHfFjZNNjjcYZWGXKeWwU4 VdlYT89JkZ+cBgIEAmwK1KJnZbO6NmNDuL/ib8buYfCUf/2RV6R9QHIynPbu9A== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1602535477; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2D9ftb4BNlPgU4fGOVcc9hqHah5NjLimpJgfMw28f+o=; b=qK6+kw4fzMu2UlI7byqtGAmPcI78XzzYUsSPXcvpiK8RQ/WaolXUVuLHhBgI49kAgKr+DQ n59ZXMNHRPEyWhCQ== To: Arnd Bergmann , Geert Uytterhoeven Cc: Linux Kernel Mailing List , Russell King , Tony Luck , Fenghua Yu , Greg Ungerer , Finn Thain , Philip Blundell , Joshua Thompson , Sam Creasey , "James E.J. Bottomley" , Helge Deller , Daniel Lezcano , John Stultz , Stephen Boyd , Linus Walleij , "linux-ia64\@vger.kernel.org" , Parisc List , linux-m68k , Linux ARM Subject: Re: [PATCH 11/13] timekeeping: remove xtime_update In-Reply-To: References: <20201008154651.1901126-1-arnd@arndb.de> <20201008154651.1901126-12-arnd@arndb.de> Date: Mon, 12 Oct 2020 22:44:36 +0200 Message-ID: <87pn5np423.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 12 2020 at 15:37, Arnd Bergmann wrote: > On Mon, Oct 12, 2020 at 3:16 PM Geert Uytterhoeven wrote: >> On Thu, Oct 8, 2020 at 5:48 PM Arnd Bergmann wrote: >> The comment about xtime_update() in arch/ia64/kernel/time.c needs >> an update. > > I think the correct action for ia64 would be to make it a > proper clockevent driver with oneshot support, and remove > the rest of this logic. Correct action would be to remove all of arch/ia64 :) > I could try to rewrite the comment, but I tried not to touch that > part since I don't understand the logic behind it. Maybe the > ia64 maintainers can comment here why it even tries to skip > a timer tick. Is there a danger of ending up with the timer irq > permanently disabled if the timer_interrupt() function returns > with the itm register in the past, or is this simply about not having > too many interrupts in a row? There was a comment in the initial ia64 code: * There is a race condition here: to be on the "safe" * side, we process timer ticks until itm.next is * ahead of the itc by at least half the timer * interval. This should give us enough time to set * the new itm value without losing a timer tick. The ITM (Interval Timer Match) register is raising an interrupt when the ITM value matches the ITC (Interval Timer Counter) register. If the new counter is already past the match then the timer interrupt will happen once ITC wrapped around and reaches the match value again. Might take ages for a 64bit counter to do that. :) IIRC, PXA had the same problem and HPET definitely has it as well. Seems Intel patented the concept of broken timers, but at least they listened when they proposed to implement the TSC deadline timer on x86 in the exact same way. See hpet_clkevt_set_next_event() for the gory details how to handle that correctly. Thanks, tglx