Re: [PATCH 0/3] Optimize code generation during context

[David Hildenbrand <david@redhat.com>]

On 25.10.25 19:37, Xie Yuanbin wrote:
> On Fri, 24 Oct 2025 17:36:06 -0400, Rik van Riel wrote:
>> Also, what kind of performance improvement
>> have you measured with these changes?
> 
> When I debugged performance issues before, I used the company's equipment.
> I could only observe the macro business performance data, but not the
> specific scheduling time. Today I did some testing using my devices,
> and the testing logic is as follows:
> ```
> -	return finish_task_switch(prev);
> +	start_time = rdtsc();
> +	barrier();
> +	rq = finish_task_switch(prev);
> +	barrier();
> +	end_time = rdtsc;
> +	return rq;
> ```
> 
> The test data is as follows:
> 1. mitigations Off, without patches: 13.5 - 13.7
> 2. mitigations Off, with patches: 13.5 - 13.7
> 3. mitigations On, without patches: 23.3 - 23.6
> 4. mitigations On, with patches: 16.6 - 16.8

Such numbers absolutely have to be part of the relevant patches / cover 
letter to show that the compiler is not actually smart enough to make a 
good decision.

Having that said, sometimes it helps to understand "why" the compiler 
does a bad job, and try to tackle that instead.

For example, compilers will not inline functions that might be too big 
(there is a compiler tunable), factoring out slow-paths etc could help 
to convince the compiler to do the right thing.

Of course, it's not always possible, and sometimes we just now that we 
always want to inline.

-- 
Cheers

David / dhildenb


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