* Ingo Molnar (mingo@xxxxxxx) wrote: > > * Ingo Molnar <mingo@xxxxxxx> wrote: > > > > This code is very much tied with the kernel scheduler. [...] > > > > It would not be particularly complex to enable user-space to > > request a callback on context switch events. > > > > I was thinking on and off about allowing perf events to generate a > > per sampling event notification signal on specific events, such as > > page faults or context switches. > > I was thinking about that on and off so loudly that Peter implemented > it long ago via fasync support on the perf event fd! :-) > > So if you set a notification signal via fcntl(F_SETOWN) on the > scheduler context switch event fd, the user-space RCU code will get a > signal on every context switch. > > I have not tried it for this purpose yet, so let us know if there are > unexpected complications :) I'm worried about the following complications: Let's define per-process, per-cpu data structures, mapped in userland, that keep track of the per-cpu read-side C.S. nesting count. Let say we use this signal-based mechanism to inform userland of migrations. 1) The first thing I notice is that we're not informed of threads being blocked. So multiple threads taking read-side C.S. in turn on the same CPU as they are being scheduled will corrupt each other's read-side C.S. counter. 2) The second thing I notice is that there is no form of synchronization between the userland execution and delivery of this signal, which leads to interesting race conditions. Any thoughts on how to address these ? Thanks, Mathieu -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
