All of lore.kernel.org
 help / color / mirror / Atom feed
* [Xenomai] [PATCH 0/1] rtdm: get spinlocks to lock the scheduler
@ 2012-10-12  6:24 Gilles Chanteperdrix
  2012-10-12  6:26 ` [Xenomai] [PATCH 1/1] " Gilles Chanteperdrix
  0 siblings, 1 reply; 6+ messages in thread
From: Gilles Chanteperdrix @ 2012-10-12  6:24 UTC (permalink / raw)
  To: Xenomai


Hi,

here is the second attempt to try and allow drivers to wake-up threads
in the middle of spinlock sections. The idea is to try and have a
lighter version of __xnpod_lock_sched/__xnpod_unlock_sched and use that
in the RTDM spinlocks.

The lighter version of __xnpod_lock_sched/__xnpod_unlock_sched uses a
status bit, and a preemption count in the scheduler structure, but as we
want to allow a thread to suspend itself when the scheduler is locked,
when this happens, we save the preemption count in the thread structure,
and clear the preemption count and scheduler bit, they get restore in
xnpod_schedule/xnshadow epilogue when waking-up such a thread.

We have to keep the thread XNLOCK bit, it is more or less part of the
ABI (for instance, it is possible to create a thread with this bit set,
and the scheduler is locked immediately when this thread is first
scheduled). I guess we can completely remove it in -forge though.

I have failed to modify xnlock services to also use the scheduler lock,
xnheap_init is called before the scheduler is initialized, and takes an
xnlock.

Regards.

-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 6+ messages in thread
* [Xenomai] [PATCH 0/1 v3] rtdm: get spinlocks to lock the scheduler
@ 2012-10-13 11:27 Gilles Chanteperdrix
  2012-10-13 11:30 ` [Xenomai] [PATCH 1/1] " Gilles Chanteperdrix
  0 siblings, 1 reply; 6+ messages in thread
From: Gilles Chanteperdrix @ 2012-10-13 11:27 UTC (permalink / raw)
  To: Xenomai


Hi,

here is the latest attempt to avoid entering __xnpod_schedule when
xnpod_unlock_sched is called without a needed rescheduling.

This one is much simpler. We do not try to prevent entering
__xnpod_schedule when xnpod_schedule is called with the scheduler
locked: it may be racy when the current thread wants to suspend with the
scheduler locked, and would avoid sending the reschedule IPIs to other
cpus if the other cpus scheduler state was changed. Instead, if
xnpod_schedule is called with the scheduler locked, but not to suspend
the current thread, exit early keeping the resched bit set. This avoids
having to set the resched bit in xnpod_unlock_sched and thus entering
__xnpod_schedule every time.

As with the previous patch, no attempt is made to lock the scheduler for
the implementation of xnlock* services, as they are called at a time
during the early init where xnpod_current_thread() is NULL.

Regards.

-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2012-10-19  4:50 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-10-12  6:24 [Xenomai] [PATCH 0/1] rtdm: get spinlocks to lock the scheduler Gilles Chanteperdrix
2012-10-12  6:26 ` [Xenomai] [PATCH 1/1] " Gilles Chanteperdrix
2012-10-12  6:51   ` Gilles Chanteperdrix
2012-10-12  9:38     ` Gilles Chanteperdrix
  -- strict thread matches above, loose matches on Subject: below --
2012-10-13 11:27 [Xenomai] [PATCH 0/1 v3] " Gilles Chanteperdrix
2012-10-13 11:30 ` [Xenomai] [PATCH 1/1] " Gilles Chanteperdrix
2012-10-19  4:50   ` Gilles Chanteperdrix

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.