Skip to content

适配aarch64架构机器及性能优化。 - #225

Open
Zak-Young wants to merge 6 commits into
Tencent:masterfrom
Zak-Young:master
Open

适配aarch64架构机器及性能优化。#225
Zak-Young wants to merge 6 commits into
Tencent:masterfrom
Zak-Young:master

Conversation

@Zak-Young

@Zak-Young Zak-Young commented Aug 5, 2026

Copy link
Copy Markdown

本次提交包含两个commit:

  1. 适配aarch64架构机器,包含编译框架修改及相关寄存器的定义、sp栈获取方式等。
  2. 识别到libco业务热点为memcpy,添加memcpy接口的neon优化。
    2.1. 针对不同的拷贝长度添加不同的实现。
    2.2. 针对拷贝完成后的下一步动作决定读写指令。针对写入堆栈操作,使用ldp+stnp指令,避免写入数据污染cache。针对堆栈恢复操作使用ldnp+stp,将下一步待执行任务导入cache。
  3. neon优化的memcpy接口对不同size的栈大小收益不同。针对32K共享栈,1000协程、2000次协程切换测试场景,4K~8K场景协程切换性能提升12% - 14%。在1K - 4k场景有4%~12%收益。在较小栈与较大栈(大于16K)场景下收益甚微,在较小栈无法发挥NEON指令带宽优势,较大栈场景cache miss成为业务瓶颈。

Zuko917 added 2 commits August 3, 2026 14:59
Directory restructuring:
- Move source files to lib/ and examples/ subdirectories
- Add separate CMakeLists.txt for lib/ and examples/

aarch64 platform adaptation:
- Add aarch64 context switch assembly (coctx_swap.S)
- Add aarch64 coctx_make implementation
- Add get_sp() helper for stack pointer on aarch64
- Add co_free_sharestack() and co_destruct_curr_thread_env() APIs
- Fix memory leaks (set pointers to nullptr after free)
- Add shared stack parameter validation
- Split co_memcpy into co_memcpy_save (ldp+stnp) and co_memcpy_swap (ldnp+stp)
- save: write-not-immediately-read, non-temporal store avoids cache pollution
- swap: write-immediately-read, non-temporal load + temporal store for cache locality
- <=1KB uses memcpy_blk (128B blocks), >1KB uses 384B block loop
- Parameterized NEON macros: memcpy_blk_neon and memcpy_384B_neon with ld/st hints
- 64-byte dst alignment pre-processing preserved
@tencent-adm

Copy link
Copy Markdown
Member

CLA assistant check
Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

Zuko917 added 4 commits August 5, 2026 15:27
OP-1: Inline 32B NEON remainder handling in 384B/512B macros,
      eliminating memcpy_rem call overhead for common remainder
      sizes (32/64/96B). Fixes 4K+64B ~3% regression.

OP-2: Instruction reschedule in 512B loop - load-store spacing
      increased to >=3 instructions to hide ARM load latency
      (3-4 cycles on Cortex-A72/A76).

OP-3: New 512B (4x128B) block path for >4KB data, reducing loop
      overhead by 25% vs 384B. Register reuse (q0-q7 recycled
      after G1 stores complete).

OP-4: Remainder handling inherits save/swap temporal strategy
      (ldp+stnp for save, ldnp+stp for swap) automatically,
      extending cache pollution control to remainder bytes.
OP-5: Retune block-size thresholds: 1K→128B, 2K→384B, 8K→512B,
      >8K→1024B. 2K-4K cases now use 512B path (+5% expected).

OP-6: New 1024B (8x128B) block path for >8KB data. Register reuse
      across 4 groups (q0-q7, q16-q23 recycled). 50% fewer loop
      iterations vs 512B. Tail handles 4/1-block remainders inline.
OP-7: New 1536B (12x128B) block path for >12KB data. Register
      reuse across 3 groups (q0-q7, q16-q23 recycled 3 times).
      33% fewer loop iterations vs 1024B. Tail handles 8/4/1-block
      remainders inline.

Tier thresholds: 1K→128B, 2K→384B, 8K→512B, 12K→1024B, >12K→1536B.
OP-8: New 256B (2x128B) block path for 1K-2K data. Halves loop
      iterations vs 128B blocks. Fixes 1088B regression (0.990).
      Register reuse: q0-q7 loaded twice per iteration.

6-tier: 1K→128B, 2K→256B, 4K→384B, 8K→512B, 12K→1024B, >12K→1536B
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants