Hello! Some recent patches [1] include changes providing srcu_read_lock_fast(), srcu_read_unlock_fast(), srcu_down_read(), and srcu_up_read(), which incur about 20% less read-side overhead than RCU Tasks Trace's rcu_read_lock_trace() and rcu_read_unlock_trace(), as well as about an order of magnitude less overhead than srcu_read_lock() and srcu_read_unlock(). In both cases, these performance numbers were collected using an unrealistic empty-reader benchmark on my laptop. These new SRCU-fast read-side APIs are likely to be used for uretprobes [2], but might be useful elsewhere. The goal of this proposal is to gain additional feedback for SRCU-fast and to see what other uses it might be put to. A quick "find" command locate instances of srcu_read_lock() in the fs, mm, and block subsystems, so I CCed those lists just in case. If things go well, I expect these to go into the v6.15 merge window. More details and tradeoffs below. Thanx, Paul ------------------------------------------------------------------------ SRCU-fast's increased read-side performance does not come for free. Here are some downsides compared to both RCU Tasks Trace and stock SRCU (as in the srcu_read_lock() function): o SRCU-fast readers are permitted only where rcu_is_watching() returns true. Downsides compared to stock SRCU: o In the absence of readers, a synchronize_srcu() having _fast() readers will incur the latency of at least two normal RCU grace periods. For purposes of comparison, in the absence of readers, an isolated stock SRCU grace period might incur sub-millisecond latency. (However, this latency is artificially increased when there are concurrent SRCU grace periods for the same srcu_struct in order to limit CPU utilization.) o The srcu_read_lock() function returns an int that must be passed to the matching srcu_read_unlock(), which is a 32-bit quantity. In contrast, on 64-bit systems srcu_read_lock_fast() returns a 64-bit pointer that must be passed to the matching srcu_read_unlock_fast(). o SRCU-fast readers are NMI-safe (as are those of RCU Tasks Trace), which means that they incur additional atomic-instruction overhead on systems having NMIs but not NMI-safe implementations of this_cpu_inc(). These systems are arm, mips, powerpc, sh, and sparc. Note "arm", as in 32-bit. The 64-bit arm64 systems have full-speed SRCU-fast readers. Downsides compared to RCU Tasks Trace: o There are no SRCU CPU stall warnings. (Some might consider this an advantage, at least until they were in a debugging session in need of such warnings.) o The rcu_read_lock_trace() function is of void type. In contrast, srcu_read_lock_fast() returns a pointer that must be passed to the matching srcu_read_unlock_fast(). o Neither RCU Tasks Trace nor SRCU provide priority boosting, in part because boosting a blocked (as opposed to preempted) reader is unhelpful. However, if some use case arose where boosting actually made sense, it could be added to RCU Tasks Trace more easily (and with less overhead) than to SRCU. On the other hand, SRCU-fast has a couple of advantages compared to RCU Tasks Trace: o RCU Tasks Trace uses a scheduler hook, and SRCU (whether fast or otherwise) needs no such hook. o SRCU-fast provides the srcu_down_read_fast() and srcu_up_read_fast() functions, which allow entering a read-side critical section in one context (for example, task level) and exiting it in another (for example, in a timer handler). This might not be impossible to provide in RCU Tasks Trace, but some thought would be required due to RCU Tasks Trace's current reliance on the task_struct structure. [1] https://lore.kernel.org/all/1034ef54-b6b3-42bb-9bd8-4c37c164950d@paulmck-laptop/ [2] https://lore.kernel.org/all/20240903174603.3554182-1-andrii@xxxxxxxxxx/
