Messages in this thread | | | Date | Thu, 26 Mar 2015 09:53:02 -0400 | From | Steven Rostedt <> | Subject | Re: [PATCH RT 2/4] Revert "timers: do not raise softirq unconditionally" |
| |
On Thu, 26 Mar 2015 07:27:30 +0100 Mike Galbraith <umgwanakikbuti@gmail.com> wrote:
> On Thu, 2015-03-26 at 06:23 +0100, Mike Galbraith wrote: > > > I plan on taking a poke at getting "don't raise timer unconditionally" > > working again when I get myself unburied, and see if I can come up with > > a somewhat less icky way to work around take rtmutex in irq naughtiness. > > Hm.. like maybe only do a fasttrylock with the wait lock already held > via trylock, and don't bother turning it loose until we're done, to keep > the sane people away. That might work.. but may not be considered less > icky by people equipped with that mysterious "taste" thingy ;-)
You would still need to add some ownership so that all will fail the fast path.
You mean create a spin_trylock_in_hirq() which would just lock the waitlock and not even do the fast path with the rt_mutex.
if (!raw_spin_trylock(waitlock)) goto failed_lock;
if (!try_to_take_rt_mutex()) { raw_spin_unlock(waitlock); goto failed_lock; }
return success;
With the waitlock held, no slow path will get to the pi code. Then you have a spin_unlock_in_hirq() that would go right into the slow path assuming the waitlock is already held.
Sounds reasonable to me.
-- Steve
| |