Message ID | 20221228004444.61568-1-samuel@sholland.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp1652409wrt; Tue, 27 Dec 2022 16:47:32 -0800 (PST) X-Google-Smtp-Source: AMrXdXvOqWOEXJB8sCdDsGdlmSuMJwFuHb3j3rN0Lbd9rwQ+diRN/7reM9Vo3VXLFx/VxpbT0DZ3 X-Received: by 2002:aa7:ccc2:0:b0:477:8ab8:43e0 with SMTP id y2-20020aa7ccc2000000b004778ab843e0mr19296051edt.2.1672188452056; Tue, 27 Dec 2022 16:47:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672188452; cv=none; d=google.com; s=arc-20160816; b=SZFaQWY1Rq9qfkKPS6/8YICeYlWwtcP+YL1N26C760wLeo9pZ700K5R9+sBy43HJza mDexuBQIQE0OPbaSslspzcl50jI2JYabk/jROOP64yU9sf+eripDPUX9m50lxJrUelK7 m5l7sSgagIR60NUFtUxhYI3x/tChhF4Pd2LxxK5kPoFw9Lqq8IPpuXBz2a/vaAUldHwj V9tyNxU9NhKGVkqCYOrx7Qlro4+hRtgJRgK7flJxa+9cn0BA1j/AOQt0LzlLjpIyhvO+ Uvfms+hq7JGiVoYbwBBRObJC9Pol4CEcIUEcu0H0j7HPT3TIm1d7d/3YHcDqfdgupTr/ 0TWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:feedback-id:dkim-signature :dkim-signature; bh=lJKh5hLUSVyNtGb27sEl8iKUopQtksa0I8JjuVzm/jY=; b=DvNC0NA/8DSVvCeTnnIxRBlbWzp4w3V7uH2V22zEL7FxzUXR8Q4nUJNhrFhinaOlPr QxUSlZdnW50Ef+bs1XvoOvuKB7NGHn9IzhA62QbjOdra6/6rYoZKQQDryByr8rlTqp5T i9T69JF8cp9LfGTsdWkbbT29a1Hz4DJNKMyJJn15bMDsbJo6eyPIFbhQTjTG3Pf/Pz4e Sz5ODP77UYnxn+jFKmy0v1YoAtPuHwNckoFsSAd8gE4Nyc+5NofRO68+EArDQiRP3fvz oyhNAR0BhB2hZERLRfxqaOhgiLXQrgO4nBQIeErNUOAfLIiYpsfMXX0fYk7eomhfsxUt pH4g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sholland.org header.s=fm3 header.b=zsXQvkbc; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=jpUgIno+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sholland.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j19-20020a05640211d300b004700047ef96si14378698edw.289.2022.12.27.16.47.07; Tue, 27 Dec 2022 16:47:32 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@sholland.org header.s=fm3 header.b=zsXQvkbc; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=jpUgIno+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sholland.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230213AbiL1Aoy (ORCPT <rfc822;eddaouddi.ayoub@gmail.com> + 99 others); Tue, 27 Dec 2022 19:44:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48530 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229674AbiL1Aot (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 27 Dec 2022 19:44:49 -0500 Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 33C5ADFB8 for <linux-kernel@vger.kernel.org>; Tue, 27 Dec 2022 16:44:49 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D7B5B5C00CC; Tue, 27 Dec 2022 19:44:46 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 27 Dec 2022 19:44:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sholland.org; h= cc:cc:content-transfer-encoding:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:sender:subject:subject:to:to; s=fm3; t=1672188286; x=1672274686; bh=lJKh5hLUSVyNtGb27sEl8iKUo pQtksa0I8JjuVzm/jY=; b=zsXQvkbc4qvvStb1M0jQ5bPd3f+tBhq0STct4u3nu QFwp83KoW0i4X//TVOFdjcNsGpo1Oc38whYYa4fcxGZZ2eckTsIBQzascSQqMPP8 6OVXIpr4QS8lrMMTycvQ91m6h4MABLc40u0OqDZrJBcGVSwkIfn+8Ccw333WRn/o OKeY58lnAe0WBBFmQeUQFR4qZzeXq7m4JcZlPBMBwtsb30OK9N8DOfDdvrlofZtM PaYpS2orM7rveegfgrhS8t5AIsR+VvHlMG/64g7Eu8EEkiqSvkapcpYnVuxzuOtO wltFE3GW16yFFeXEIMF+HykbGcx2QWkWNG51VzbZTeSdw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1672188286; x=1672274686; bh=lJKh5hLUSVyNtGb27sEl8iKUopQtksa0I8J juVzm/jY=; b=jpUgIno+86qYFaeGQn5+s30NUnkg/CCRVzjVp9GW/E0dR7mLEL6 0DZXdgLmi4IMPbDCHBE6s3l6QB+KlxDqkQernCkEGU2ihv+i16/qN+hh+qornvRW iFBeM82wFAPlLX4qBIGjFMdw3ttGCWogLIZoXxqtEM2fEHC/r5Fg5EzdEBMf8lLV 0DRy/AoepLZX1Gdu93AduwHcuDl1i957/hv5Es+1pO6bFDj34JJty1Af5u5HfPdF qbkN18LEkOeCeLS54EDRbc9ELnnqA8p7qMbMtdxFAKtYA+m/eQlKTsStnCSvhrOL aT/WId0KvRn/4djCWMHJxr8BoTi89658xVg== X-ME-Sender: <xms:fpGrYwPR4xuCgO4e8y3P4kgryvMjk42PLPqwkWkoMEUIv3yhqZ5w0Q> <xme:fpGrY2_Mgh6SUqXB3ZIOmu2p2OjixDgn19CWxyBsVtHs3SKDvCDgW-jpLL_dugSev Pd_XqC8j6VxseP_hg> X-ME-Received: <xmr:fpGrY3QdETEsIgjk2Ux7Dl81HunUTSYYv6VmsQTyWSeYgQ58vR-14Tv6BeEuJHSIP7YX_dYVHSb0qiLGdqbCW_3sULwLMM941T22UNW1VjW0fAFXaWEVWGinr7qTtQOzWC2YNA> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedriedugddvjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkffoggfgsedtkeertdertddtnecuhfhrohhmpefurghmuhgvlhcu jfholhhlrghnugcuoehsrghmuhgvlhesshhhohhllhgrnhgurdhorhhgqeenucggtffrrg htthgvrhhnpeekveelhfejueelleetvdejvdeffeetgeelheeujeffhefgffefkeehhffh keekgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hsrghmuhgvlhesshhhohhllhgrnhgurdhorhhg X-ME-Proxy: <xmx:fpGrY4suk0hdHM_fE1N5dEqeRltOyr9UMHDbkEc3qJa3vTaFnMv_wA> <xmx:fpGrY4d349C_7MaAlYDu9H52k22l5DFzr0D5ndAdsyDjxF0N6r2nLQ> <xmx:fpGrY83KlxEYWxV4AhgP7btqrSfpWVu29JBVjUs1vfimRgLwes5UBg> <xmx:fpGrY2tQhPmgQHCdvI7buI3rSUz3bXzdEKsHeUnnZLA2DefNNoaDMQ> Feedback-ID: i0ad843c9:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 27 Dec 2022 19:44:45 -0500 (EST) From: Samuel Holland <samuel@sholland.org> To: Palmer Dabbelt <palmer@dabbelt.com>, Daniel Lezcano <daniel.lezcano@linaro.org>, Thomas Gleixner <tglx@linutronix.de> Cc: Prabhakar Lad <prabhakar.csengg@gmail.com>, Samuel Holland <samuel@sholland.org>, Albert Ou <aou@eecs.berkeley.edu>, Paul Walmsley <paul.walmsley@sifive.com>, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org Subject: [PATCH] clocksource/drivers/riscv: Increase the clock source rating Date: Tue, 27 Dec 2022 18:44:44 -0600 Message-Id: <20221228004444.61568-1-samuel@sholland.org> X-Mailer: git-send-email 2.37.4 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1753416678341176588?= X-GMAIL-MSGID: =?utf-8?q?1753416678341176588?= |
Series |
clocksource/drivers/riscv: Increase the clock source rating
|
|
Commit Message
Samuel Holland
Dec. 28, 2022, 12:44 a.m. UTC
RISC-V provides an architectural clock source via the time CSR. This
clock source exposes a 64-bit counter synchronized across all CPUs.
Because it is accessed using a CSR, it is much more efficient to read
than MMIO clock sources. For example, on the Allwinner D1, reading the
sun4i timer in a loop takes 131 cycles/iteration, while reading the
RISC-V time CSR takes only 5 cycles/iteration.
Adjust the RISC-V clock source rating so it is preferred over the
various platform-specific MMIO clock sources.
Signed-off-by: Samuel Holland <samuel@sholland.org>
---
drivers/clocksource/timer-riscv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Wed, Dec 28, 2022 at 6:14 AM Samuel Holland <samuel@sholland.org> wrote: > > RISC-V provides an architectural clock source via the time CSR. This > clock source exposes a 64-bit counter synchronized across all CPUs. > Because it is accessed using a CSR, it is much more efficient to read > than MMIO clock sources. For example, on the Allwinner D1, reading the > sun4i timer in a loop takes 131 cycles/iteration, while reading the > RISC-V time CSR takes only 5 cycles/iteration. > > Adjust the RISC-V clock source rating so it is preferred over the > various platform-specific MMIO clock sources. > > Signed-off-by: Samuel Holland <samuel@sholland.org> Looks good to me. Reviewed-by: Anup Patel <anup@brainfault.org> Regards, Anup > --- > > drivers/clocksource/timer-riscv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/clocksource/timer-riscv.c b/drivers/clocksource/timer-riscv.c > index a0d66fabf073..55dad7965f43 100644 > --- a/drivers/clocksource/timer-riscv.c > +++ b/drivers/clocksource/timer-riscv.c > @@ -73,7 +73,7 @@ static u64 notrace riscv_sched_clock(void) > > static struct clocksource riscv_clocksource = { > .name = "riscv_clocksource", > - .rating = 300, > + .rating = 400, > .mask = CLOCKSOURCE_MASK(64), > .flags = CLOCK_SOURCE_IS_CONTINUOUS, > .read = riscv_clocksource_rdtime, > -- > 2.37.4 >
Hi Samuel, Thank you for the patch. On Wed, Dec 28, 2022 at 12:44 AM Samuel Holland <samuel@sholland.org> wrote: > > RISC-V provides an architectural clock source via the time CSR. This > clock source exposes a 64-bit counter synchronized across all CPUs. > Because it is accessed using a CSR, it is much more efficient to read > than MMIO clock sources. For example, on the Allwinner D1, reading the > sun4i timer in a loop takes 131 cycles/iteration, while reading the > RISC-V time CSR takes only 5 cycles/iteration. > > Adjust the RISC-V clock source rating so it is preferred over the > various platform-specific MMIO clock sources. > > Signed-off-by: Samuel Holland <samuel@sholland.org> > --- > > drivers/clocksource/timer-riscv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Cheers, Prabhakar > diff --git a/drivers/clocksource/timer-riscv.c b/drivers/clocksource/timer-riscv.c > index a0d66fabf073..55dad7965f43 100644 > --- a/drivers/clocksource/timer-riscv.c > +++ b/drivers/clocksource/timer-riscv.c > @@ -73,7 +73,7 @@ static u64 notrace riscv_sched_clock(void) > > static struct clocksource riscv_clocksource = { > .name = "riscv_clocksource", > - .rating = 300, > + .rating = 400, > .mask = CLOCKSOURCE_MASK(64), > .flags = CLOCK_SOURCE_IS_CONTINUOUS, > .read = riscv_clocksource_rdtime, > -- > 2.37.4 >
On Tue, 27 Dec 2022 16:44:44 PST (-0800), samuel@sholland.org wrote: > RISC-V provides an architectural clock source via the time CSR. This > clock source exposes a 64-bit counter synchronized across all CPUs. > Because it is accessed using a CSR, it is much more efficient to read > than MMIO clock sources. For example, on the Allwinner D1, reading the > sun4i timer in a loop takes 131 cycles/iteration, while reading the > RISC-V time CSR takes only 5 cycles/iteration. > > Adjust the RISC-V clock source rating so it is preferred over the > various platform-specific MMIO clock sources. > > Signed-off-by: Samuel Holland <samuel@sholland.org> > --- > > drivers/clocksource/timer-riscv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/clocksource/timer-riscv.c b/drivers/clocksource/timer-riscv.c > index a0d66fabf073..55dad7965f43 100644 > --- a/drivers/clocksource/timer-riscv.c > +++ b/drivers/clocksource/timer-riscv.c > @@ -73,7 +73,7 @@ static u64 notrace riscv_sched_clock(void) > > static struct clocksource riscv_clocksource = { > .name = "riscv_clocksource", > - .rating = 300, > + .rating = 400, > .mask = CLOCKSOURCE_MASK(64), > .flags = CLOCK_SOURCE_IS_CONTINUOUS, > .read = riscv_clocksource_rdtime, I've never really understood what we're supposed to do here, it seems like we're just picking arbitrary ratings for the various clock drivers to get the one we want. That's really a property of the whole platform, though, not the drivers, so trying to encode it as part of the driver seems awkward -- if anything I'd expect the ISA clock drivers to be the worst on any platform, as otherwise what's the point of adding the platform-specific mechanism? That said, I'm fine with this as long as it's improving things on the platforms that actually exist. IIUC it's only the D1 that has multiple clock drivers currently, so if it's good there it's good for me. We'll go crazy trying to reason about all possible future hardware, so we can just sort out how to make stuff work as it shows up. So: Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> I'll let the clock folks chime in, happy to take it through the RISC-V tree but unless someone says something I'm going to assume it's aimed over there. Thanks!
Hi Palmer, On 12/29/22 10:22, Palmer Dabbelt wrote: > On Tue, 27 Dec 2022 16:44:44 PST (-0800), samuel@sholland.org wrote: >> RISC-V provides an architectural clock source via the time CSR. This >> clock source exposes a 64-bit counter synchronized across all CPUs. >> Because it is accessed using a CSR, it is much more efficient to read >> than MMIO clock sources. For example, on the Allwinner D1, reading the >> sun4i timer in a loop takes 131 cycles/iteration, while reading the >> RISC-V time CSR takes only 5 cycles/iteration. >> >> Adjust the RISC-V clock source rating so it is preferred over the >> various platform-specific MMIO clock sources. >> >> Signed-off-by: Samuel Holland <samuel@sholland.org> >> --- >> >> drivers/clocksource/timer-riscv.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/clocksource/timer-riscv.c >> b/drivers/clocksource/timer-riscv.c >> index a0d66fabf073..55dad7965f43 100644 >> --- a/drivers/clocksource/timer-riscv.c >> +++ b/drivers/clocksource/timer-riscv.c >> @@ -73,7 +73,7 @@ static u64 notrace riscv_sched_clock(void) >> >> static struct clocksource riscv_clocksource = { >> .name = "riscv_clocksource", >> - .rating = 300, >> + .rating = 400, >> .mask = CLOCKSOURCE_MASK(64), >> .flags = CLOCK_SOURCE_IS_CONTINUOUS, >> .read = riscv_clocksource_rdtime, > > I've never really understood what we're supposed to do here, it seems > like we're just picking arbitrary ratings for the various clock drivers > to get the one we want. That's really a property of the whole platform, > though, not the drivers, so trying to encode it as part of the driver > seems awkward -- if anything I'd expect the ISA clock drivers to be the > worst on any platform, as otherwise what's the point of adding the > platform-specific mechanism? For sunxi at least, the platform-specific MMIO timers came first, as the ARM architectural timer was not implemented in the first couple of SoCs. The ARM architectural timer was universally better for timekeeping (percpu events, faster access, larger range), so we completely ignored the MMIO timers once it was available. We eventually went back and enabled the MMIO timers everywhere because they are useful for PM. Either they don't have CLOCK_EVT_FEAT_C3STOP, or they do have CLOCK_SOURCE_SUSPEND_NONSTOP, or both. I imagine the RISC-V situation will be similar. The time CSR will be used as the primary clocksource and for sched_clock, while MMIO clock sources will only be used in specific PM scenarios where the time CSR is unavailable. Plus there is the distinction between clock sources and clock events. Drivers usually provide both, but there is no requirement that both be used. The RISC-V architecture provides a high quality clock source (time CSR) but a poor quality clock event (SBI call) unless Sstc is available. So platforms without Sstc may use a combination of drivers: the RISC-V clock source along with a platform-specific clock event. > That said, I'm fine with this as long as it's improving things on the > platforms that actually exist. IIUC it's only the D1 that has multiple > clock drivers currently, so if it's good there it's good for me. We'll RZ/Five also has a platform MMIO timer driver[1]. [1]: https://lore.kernel.org/lkml/20221211215843.24024-1-prabhakar.mahadev-lad.rj@bp.renesas.com/ > go crazy trying to reason about all possible future hardware, so we can > just sort out how to make stuff work as it shows up. So: > > Acked-by: Palmer Dabbelt <palmer@rivosinc.com> > Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> > > I'll let the clock folks chime in, happy to take it through the RISC-V > tree but unless someone says something I'm going to assume it's aimed > over there. Thanks for the review! Regards, Samuel
On 28/12/2022 01:44, Samuel Holland wrote: > RISC-V provides an architectural clock source via the time CSR. This > clock source exposes a 64-bit counter synchronized across all CPUs. > Because it is accessed using a CSR, it is much more efficient to read > than MMIO clock sources. For example, on the Allwinner D1, reading the > sun4i timer in a loop takes 131 cycles/iteration, while reading the > RISC-V time CSR takes only 5 cycles/iteration. > > Adjust the RISC-V clock source rating so it is preferred over the > various platform-specific MMIO clock sources. > > Signed-off-by: Samuel Holland <samuel@sholland.org> > --- Applied, thanks
diff --git a/drivers/clocksource/timer-riscv.c b/drivers/clocksource/timer-riscv.c index a0d66fabf073..55dad7965f43 100644 --- a/drivers/clocksource/timer-riscv.c +++ b/drivers/clocksource/timer-riscv.c @@ -73,7 +73,7 @@ static u64 notrace riscv_sched_clock(void) static struct clocksource riscv_clocksource = { .name = "riscv_clocksource", - .rating = 300, + .rating = 400, .mask = CLOCKSOURCE_MASK(64), .flags = CLOCK_SOURCE_IS_CONTINUOUS, .read = riscv_clocksource_rdtime,