Page MenuHomeFreeBSD

arm64 vfp: eliminate nested critical sections
ClosedPublic

Authored by alc on Aug 15 2026, 4:49 PM.
Tags
None
Referenced Files
F172952818: D58859.id184097.diff
Tue, Sep 22, 9:04 AM
Unknown Object (File)
Sun, Sep 20, 5:07 PM
Unknown Object (File)
Fri, Sep 18, 4:18 PM
Unknown Object (File)
Wed, Sep 16, 3:06 AM
Unknown Object (File)
Tue, Sep 15, 1:00 PM
Unknown Object (File)
Mon, Sep 14, 8:17 AM
Unknown Object (File)
Sat, Sep 12, 10:08 PM
Unknown Object (File)
Sat, Sep 12, 3:22 PM
Subscribers

Details

Summary

At two out of three call sites to vfp_restore_state_common(), the caller must use critical_{enter,exit} to prevent preemption between its call to vfp_restore_state_common() and other actions, notably its call to sve_enable(). So, it is arguably better to make vfp_restore_state_common()'s caller responsible for performing critical_{enter,exit} and simply perform CRITICAL_ASSERT() inside vfp_restore_state_common().

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

alc requested review of this revision.Aug 15 2026, 4:49 PM
sys/arm64/arm64/vfp.c
738

Is it better to dereference curthread outside of the section (for some value of 'better')?

sys/arm64/arm64/vfp.c
738

One load instruction moves out of the critical section, and moving it doesn't create any more register pressure. That instruction is going to be a cache hit (when inside the critical section) because critical_enter() itself fetches curthread. Unfortunately, wherever you place td = curthread;, the compiler has to generate two load instructions for curthread. It can't eliminate one because volatile blocks common subexpression expression.

I'm pretty much indifferent to where td = curthread; goes, so I'm happy to move it.

This revision is now accepted and ready to land.Aug 15 2026, 10:44 PM

Move td = curthread; out of the critical section.

This revision now requires review to proceed.Aug 15 2026, 10:54 PM
This revision is now accepted and ready to land.Aug 17 2026, 12:18 PM
This revision was automatically updated to reflect the committed changes.