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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 C1C84C433B4 for ; Sat, 10 Apr 2021 09:04:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 97E7461185 for ; Sat, 10 Apr 2021 09:04:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234172AbhDJJFK (ORCPT ); Sat, 10 Apr 2021 05:05:10 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:55510 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229591AbhDJJFJ (ORCPT ); Sat, 10 Apr 2021 05:05:09 -0400 From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1618045494; 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=XpQpnV8inwurre/JMjzsAgUTER9EyXm2D3ZFREPmzIE=; b=FiQMKs55s6H/KKxDKfNbDE4g1BvVozjxlLQWoycgVzNzU92MyAHlMb5dyhJWl1WvmNKyi4 V5ZXl7fXlTGwU3ZUubwT16kGqQqzpxTgiGl4i2ml6ree3n0Et4elOc9p4nQt5nPRLP7AzN qQbLIvKNVCcDUaz3tgSujqPUB0IKUb0O21IEJCvp3Wku8c7Hm3VIBlN6kZF7et5UYw/VIG c+UxVqyFp0gy0pEijPezqQj7DOSKnsUw+Nw47M0f/DwHvHdgf1jFHw56GwtETDYxoAo2D0 KNbMajXNjdwCTDtG1d5+NT2z8gUIwlVqD3eCXgfznk6WKQ3z99x1q6tc+aDq5w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1618045494; 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=XpQpnV8inwurre/JMjzsAgUTER9EyXm2D3ZFREPmzIE=; b=18gpPar/4C44Fk/MVpz2MIfoRKolxwHlXgUQ4iO4nuVKyOvQ5FDcQCX80K/N4i0zcNuN/n SArRX3pn4OxQTmCQ== To: paulmck@kernel.org, linux-kernel@vger.kernel.org Cc: john.stultz@linaro.org, sboyd@kernel.org, corbet@lwn.net, Mark.Rutland@arm.com, maz@kernel.org, kernel-team@fb.com, neeraju@codeaurora.org, ak@linux.intel.com, "Paul E. McKenney" Subject: Re: [PATCH v7 clocksource 5/5] clocksource: Do pairwise clock-desynchronization checking In-Reply-To: <20210402224906.3912-5-paulmck@kernel.org> References: <20210402224828.GA3683@paulmck-ThinkPad-P72> <20210402224906.3912-5-paulmck@kernel.org> Date: Sat, 10 Apr 2021 11:04:54 +0200 Message-ID: <878s5q4iix.ffs@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 Fri, Apr 02 2021 at 15:49, paulmck wrote: > From: "Paul E. McKenney" > > Although smp_call_function() has the advantage of simplicity, using > it to check for cross-CPU clock desynchronization means that any CPU > being slow reduces the sensitivity of the checking across all CPUs. > And it is not uncommon for smp_call_function() latencies to be in the > hundreds of microseconds. > > This commit therefore switches to smp_call_function_single(), so that > delays from a given CPU affect only those measurements involving that > particular CPU. Is there any reason I'm missing why this is not done right in patch 3/5 which introduces this synchronization check? Thanks, tglx