On Thu, Feb 06, 2025 at 02:54:19AM -0800, Kumar Kartikeya Dwivedi wrote: > + /* > + * Find the CPU holding the lock that we want to acquire. If there is a > + * deadlock scenario, we will read a stable set on the remote CPU and > + * find the target. This would be a constant time operation instead of > + * O(NR_CPUS) if we could determine the owning CPU from a lock value, but > + * that requires increasing the size of the lock word. > + */ Is increasing the size of rqspinlock_t really a problem? For the kernel as a whole there's very little code that really relies on spinlock_t being u32 (lockref is an example that does care). And it seems to me this thing might benefit somewhat significantly from adding this little extra bit.
