On Thu, 26 Mar 2015 07:27:30 +0100
Mike Galbraith <umgwanakikb...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
