[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5f762ab8-c4d3-4ccb-af77-10c2692e5ec2@sifive.com>
Date: Thu, 28 Sep 2023 11:33:37 -0500
From: Samuel Holland <samuel.holland@...ive.com>
To: "Lad, Prabhakar" <prabhakar.csengg@...il.com>
Cc: Daniel Lezcano <daniel.lezcano@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
Samuel Holland <samuel@...lland.org>,
Anup Patel <anup@...infault.org>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Conor Dooley <conor.dooley@...rochip.com>,
Biju Das <biju.das.jz@...renesas.com>,
linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
linux-renesas-soc@...r.kernel.org,
Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [PATCH] clocksource/drivers/riscv: Increase the clock_event
rating
Hi Prabhakar,
On 2023-09-28 11:18 AM, Lad, Prabhakar wrote:
> On Thu, Sep 28, 2023 at 5:04 PM Samuel Holland
> <samuel.holland@...ive.com> wrote:
>>
>> On 2023-09-28 5:45 AM, Prabhakar wrote:
>>> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
>>>
>>> Renesas RZ/Five SoC has OSTM blocks which can be used for clock_event and
>>> clocksource [0]. The clock_event rating for the OSTM is set 300 but
>>> whereas the rating for riscv-timer clock_event is set to 100 due to which
>>> the kernel is choosing OSTM for clock_event.
>>>
>>> As riscv-timer is much more efficient than MMIO clock_event, increase the
>>> rating to 400 so that the kernel prefers riscv-timer over the MMIO based
>>> clock_event.
>>
>> This is only true if you have the Sstc extension and can set stimecmp directly.
>> Otherwise you have the overhead of an SBI call, which is going to be much higher
>> than an MMIO write. So the rating should depend on Sstc, as in this patch:
>>
>> https://lore.kernel.org/linux-riscv/20230710131902.1459180-3-apatel@ventanamicro.com/
>>
> Thank you for the pointer. Do you know any tool/util which I can use
> to make comparisons?
To measure the latency of the trap to M-mode when receiving the timer interrupt,
you could use the timerlat tracer. This computes the delta between the
programmed timestamp, and when the IRQ is actually handled.
To measure the latency of setting the timer, you could add code to compute the
duration of the set_next_event functions. (min_delta_ns won't tell you anything
because set_next_event never fails.)
Regards,
Samuel
Powered by blists - more mailing lists