Re: [PATCH v2 3/2] RISC-V: sbi: remove sbi_ecall tracepoints

From: "Radim Krčmář" <rkrcmar@ventanamicro.com>
To: "David Laight" <david.laight.linux@gmail.com>
Cc: "Palmer Dabbelt" <palmer@dabbelt.com>,
	<linux-riscv@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	<aou@eecs.berkeley.edu>, "Alexandre Ghiti" <alex@ghiti.fr>,
	"Atish Patra" <atishp@rivosinc.com>, <ajones@ventanamicro.com>,
	<cleger@rivosinc.com>, <apatel@ventanamicro.com>,
	<thomas.weissschuh@linutronix.de>,
	"Jeff Law" <jlaw@ventanamicro.com>
Subject: Re: [PATCH v2 3/2] RISC-V: sbi: remove sbi_ecall tracepoints
Date: Thu, 26 Jun 2025 10:10:48 +0200	[thread overview]
Message-ID: <DAWB9QUQGPAZ.Z5454RAZXOF7@ventanamicro.com> (raw)
In-Reply-To: <20250625093415.53fd21cf@pumpkin>

2025-06-25T09:34:15+01:00, David Laight <david.laight.linux@gmail.com>:
> On Wed, 25 Jun 2025 09:51:45 +0200
> Radim Krčmář <rkrcmar@ventanamicro.com> wrote:
>> 2025-06-24T15:09:09+02:00, Radim Krčmář <rkrcmar@ventanamicro.com>:
>> > For another example, let's have the following function:
>> >
>> >   struct sbiret some_sbi_ecall(uintptr_t a0, uintptr_t a1)
>> >   {
>> >     return sbi_ecall(123, 456, a0, a1);
>> >   }
>> >
> ...
>> 
>> GCC 15.1 still leaves "mv" outside the branch, but at least seems to be
>> on the right track (undesired overhead is marked with leading stars):
>> 
>>    0xffffffff800236e8 <+0>:	addi	sp,sp,-48
>>    0xffffffff800236ea <+2>:	sd	s0,32(sp)
>>    0xffffffff800236ec <+4>:	sd	ra,40(sp)
>>    0xffffffff800236ee <+6>:	addi	s0,sp,48
>> *  0xffffffff800236f0 <+8>:	mv	a4,a0
>> *  0xffffffff800236f2 <+10>:	mv	a5,a1
>>    0xffffffff800236f4 <+12>:	nop
>> *  0xffffffff800236f8 <+16>:	mv	a0,a4
>> *  0xffffffff800236fa <+18>:	mv	a1,a5
>>    0xffffffff800236fc <+20>:	li	a7,123
>>    0xffffffff80023700 <+24>:	li	a6,456
>>    0xffffffff80023704 <+28>:	ecall
>> *  0xffffffff80023708 <+32>:	mv	a5,a0
>> *  0xffffffff8002370a <+34>:	mv	a2,a1
>>    0xffffffff8002370c <+36>:	nop
>>    0xffffffff80023710 <+40>:	ld	ra,40(sp)
>>    0xffffffff80023712 <+42>:	ld	s0,32(sp)
>> *  0xffffffff80023714 <+44>:	mv	a0,a5
>> *  0xffffffff80023716 <+46>:	mv	a1,a2
>>    0xffffffff80023718 <+48>:	addi	sp,sp,48
>>    0xffffffff8002371a <+50>:	ret
>>    [Tracing goes to +126]
>
> How much do a few register moves/spills matter compared to the
> cost of the called code?

I didn't do any serious analysis... In general, simpler functions are
going to suffer a higher ratio of overhead from adding tracepoints, and
the constant overhead per added tracepoint increases with the number of
its arguments.

For a trap to kernel mode that passes through a dozen tracepoint sites,
we could save under a hundred instructions if disabled tracepoints had
the minimal overhead.  I don't have a good idea how much of the total
trap execution-time/instruction-count/entropy-increase that actually is.

> There will but much worse things out there if you look.

Definitely, I am trying my best not to look, but I sometimes happen to
stumble upon something, and try to understand it.

Waiting till the tracepoint overhead resolves itself sounds fine to me.

Thanks.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv