* Frank Ch. Eigler (fche@xxxxxxxxxx) wrote: > Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxx> writes: > > > [...] > > The problem is also in _stp_print_flush, not *only* in relay code: > > void _stp_print_flush (void) > > ... > > spin_lock(&_stp_print_lock); > > ... > > spin_unlock(&_stp_print_lock); > > > > Those will turn into mutexes with -rt. > > Indeed, plus systemtap-generated locking code uses rwlocks, > local_irq_save/restore or preempt_disable, in various places. Could > someone point to a place that spells out what would be more > appropriate way of ensuring atomicity while being compatible with -rt? > > - FChE AFAIK, for your needs either: - Use atomic ops - Use per-cpu data with preempt disabling/irq disabling - Use the original "real" spin locks/rwlocks (raw_*). - Don't play with timers or wakeups, since this kernel code uses the "standard" spin locks (sleepable in -rt). You just don't want to sleep in the tracing code. Make sure that the sub-buffer switch code respects that too: it is the most tricky and yet less executed part of the tracing code, so it's easy for bugs to slip there and yet be undetected for a while. Since you will likely disable preemption, make sure your tracing code executes in a deterministic time. Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
