[PATCH 0/3] Optimize code generation during context
David Hildenbrand
david at redhat.com
Wed Oct 29 03:26:39 PDT 2025
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
More information about the linux-riscv
mailing list