Accelerate access to interrupt status

[hujun260]

Summary

using percpu storage for g_current_regs or leveraging interrupt status
registers to determine if code is running within an interrupt context can enhance performance.

The benefits are very significant.
Before the modification, if we needed to obtain the interrupt status, it required three steps:

1 Obtain the CPU index
2 Access the global variable
4 Disable/Enable interrupts
This process involved at least 7 CPU instructions.

However, now it only requires a single CPU instruction.

Impact

none

Testing

ostest

[yf13]

@hujun260, Can you enrich the testing section of PR description with checked targets (with configs) and observed performance changes?

[hujun260]

@hujun260, Can you enrich the testing section of PR description with checked targets (with configs) and observed performance changes?

The benefits are very significant.
Before the modification, if we needed to obtain the interrupt status, it required three steps:

1 Obtain the CPU index
2 Access the global variable
4 Disable/Enable interrupts
This process involved at least 7 CPU instructions.

However, now it only requires a single CPU instruction.

[anchao]

The benefits are very significant. Before the modification, if we needed to obtain the interrupt status, it required three steps:

1 Obtain the CPU index 2 Access the global variable 4 Disable/Enable interrupts This process involved at least 6 CPU instructions.

However, now it only requires a single CPU instruction.

1. The switch irq enable/disable in up_interrupt_context() could be removed actually, as 32-bit is atomic type on arm32 CPU core
2. The instructions cycle timings of MCR may bring more overhead, requiring 6 cycles in the worst case

https://developer.arm.com/documentation/100026/0104/smr1465219161191

Do we have relevant performance test? For example, how many cycles does it take to call up_set_current_regs()/up_current_regs() 10,000 times with/out this PR?

[hujun260]

The benefits are very significant. Before the modification, if we needed to obtain the interrupt status, it required three steps:
1 Obtain the CPU index 2 Access the global variable 4 Disable/Enable interrupts This process involved at least 6 CPU instructions.
However, now it only requires a single CPU instruction.

1. The switch irq enable/disable in up_interrupt_context() could be removed actually, as 32-bit is atomic type on arm32 CPU core
2. The instructions cycle timings of MCR may bring more overhead, requiring 6 cycles in the worst case

https://developer.arm.com/documentation/100026/0104/smr1465219161191

Do we have relevant performance test? For example, how many cycles does it take to call up_set_current_regs()/up_current_regs() 10,000 times with/out this PR?

Firstly, irq masking cannot be removed here due to the crucial reason that we must ensure no scheduling occurs for the current task
after the cpuindex is acquired. Otherwise, the cpuindex will not correspond to the CPU where the current task resides, leading to logical errors.
The implementation of this_task follows a similar principle.

The current implementation need at least 3 executions of msr/mrs instructions plus 4 normal instructions, making this optimization evident. After optimization, only a single mrs instruction is needed, with no additional overhead.

Unfortunately, we haven't conducted tests specifically for this single optimization point alone.
Instead, we've tested the entire message sending/receiving process, and each test incorporates multiple optimization points.

[anchao]

The current implementation need at least 3 executions of msr/mrs instructions plus 4 normal instructions, making this optimization evident. After optimization, only a single mrs instruction is needed, with no additional overhead.

Have you checked the assembly code? The previous implementation only reads the Affinity ID through MRC (1 cycle) and does not call MCR. Now your implementation uses MCR instruction to save the current regs with higher overhead than before.

Unfortunately, we haven't conducted tests specifically for this single optimization point alone.
Instead, we've tested the entire message sending/receiving process, and each test incorporates multiple optimization points.

Could you provide performance diagram before and after adding this commit? Or API level test? Why you conclude that the performance is better than before without any test?

My concern is that MCR may perform worse than it currently does, but I'm not sure, could you help confirm this?

[anchao]

Firstly, irq masking cannot be removed here due to the crucial reason that we must ensure no scheduling occurs for the current task after the cpuindex is acquired. Otherwise, the cpuindex will not correspond to the CPU where the current task resides, leading to logical errors. The implementation of this_task follows a similar principle.

Yes, you are right, I forgot SMP mode, which does require disabling interrupts. I am currently using AMP/BMP mode, the performance is much higher than SMP

[hujun260]

The current implementation need at least 3 executions of msr/mrs instructions plus 4 normal instructions, making this optimization evident. After optimization, only a single mrs instruction is needed, with no additional overhead.

Have you checked the assembly code? The previous implementation only reads the Affinity ID through MRC (1 cycle) and does not call MCR. Now your implementation uses MCR instruction to save the current regs with higher overhead than before.

Unfortunately, we haven't conducted tests specifically for this single optimization point alone.
Instead, we've tested the entire message sending/receiving process, and each test incorporates multiple optimization points.

Could you provide performance diagram before and after adding this commit? Or API level test? Why you conclude that the performance is better than before without any test?

My concern is that MCR may perform worse than it currently does, but I'm not sure, could you help confirm this?

I did a test, in armv7-a arch, 200 million cycles

before:
up_current_regs + irq enable/disable
2884 ms
up_set_current_regs
1358 ms

---

after:
up_current_regs
1017 ms
up_set_current_regs
339 ms