On Thu, 26 Feb 2015 14:56:30 +0100 Sebastian Andrzej Siewior <[email protected]> wrote:
> I am not sure if we want keep doing that. The only reason why we grab > the lock in the first place was to check if there is a timer pending > and we run on the isolated CPU. It should not matter for the other CPUs, > right? > So instead going further that road, what about storing base->next_timer > someplace so it can be obtained via atomic_read() for the isolated CPUs? > If we can pull that off and remove all rtmutex trylocks from hardirq context, I would much rather do that. This hocus pocus coding is just going to lead us down the path of the black arts. I already have a black cat, so I'm good to go. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
