Messages in this thread | | | Date | Thu, 26 Jul 2007 12:22:31 -0400 | From | "Frank Ch. Eigler" <> | Subject | Re: [Question] Hooks for scheduler tracing (CFS) |
| |
Hi -
On Thu, Jul 26, 2007 at 11:02:26AM -0400, Mathieu Desnoyers wrote: > [...] > > > 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,
(Though actually that bug was fixed some time ago.)
> > 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? > > AFAIK, for your needs either: > [...] > - Use per-cpu data with preempt disabling/irq disabling
As in local_irq_save / preempt_disable? Yes, already done.
> - Use the original "real" spin locks/rwlocks (raw_*). > [...]
It was unclear from the OLS paper whether the spin_lock_irq* family of functions also had to be moved to the raw forms.
> You just don't want to sleep in the tracing code. [...] Since you > will likely disable preemption, make sure your tracing code executes > in a deterministic time.
Definitely, that has always been the case.
> Make sure that the sub-buffer switch code respects that too [...]
We will review that part of the related code.
- FChE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |