Messages in this thread | | | Date | Tue, 21 Nov 2023 11:00:13 -0500 | Subject | Re: [PATCH v4 1/5] tracing: Introduce faultable tracepoints | From | Mathieu Desnoyers <> |
| |
On 2023-11-21 10:52, Peter Zijlstra wrote: > On Tue, Nov 21, 2023 at 03:46:43PM +0100, Peter Zijlstra wrote: > >> Why is this such a hard question? > > Anyway, recapping from IRC: > > preemptible, SRCU: > counter-array based, GP advances by increasing array index > and waiting for previous index to drop to 0. > > notably, a GP can pass while a task is preempted but not within a > critical section. > > SRCU has smp_mb() in the critical sections to improve GP.
Also:
preemptible only allows blocking when priority inheritance is guarantees, which excludes doing I/O, and thus page faults. Otherwise a long I/O could cause the system to OOM.
SRCU allows all kind of blocking, as long as the entire SRCU domain does not mind waiting for a while before readers complete.
> > tasks: > waits for every task to pass schedule() > > ensures that any pieces of text rendered unreachable before, is > actually unused after. > > tasks-rude: > like tasks, but different? build to handle tracing while rcu-idle, > even though that was already deemed bad? > > tasks-tracing-rcu: > extention of tasks to have critical-sections ? Should this simply be > tasks?
tasks-trace-rcu is meant to allow tasks to block/take a page fault within the read-side. It is specialized for tracing and has a single domain. It does not need the smp_mb on the read-side, which makes it lower-overhead than SRCU.
Thanks,
Mathieu
> > > Can someone complete, please? > > >
-- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com
| |