Re: [Question] Hooks for scheduler tracing (CFS)

From: Mathieu Desnoyers
Date: Thu Jul 26 2007 - 14:35:50 EST


* Frank Ch. Eigler (fche@xxxxxxxxxx) wrote:
> 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.
>

Yes, you have them to move them too:

linux/spinlock.h:
#ifdef CONFIG_PREEMPT_RT
# define _spin_lock(l) rt_spin_lock(l)
# define _spin_lock_nested(l, s) rt_spin_lock_nested(l, s)
# define _spin_lock_bh(l) rt_spin_lock(l)
# define _spin_lock_irq(l) rt_spin_lock(l)
# define _spin_unlock(l) rt_spin_unlock(l)
# define _spin_unlock_no_resched(l) rt_spin_unlock(l)
# define _spin_unlock_bh(l) rt_spin_unlock(l)
# define _spin_unlock_irq(l) rt_spin_unlock(l)
# define _spin_unlock_irqrestore(l, f) rt_spin_unlock(l)
..

And below, both spin_lock and spin_lock_irqsave use PICK_OP to turn into
their _spin_lock_* equivalent, which are both mapped to rt_spin_lock in
-rt.

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/