Re: Regression on rt kernel while using POSIX timers

["Patel, Vedang" <vedang.patel@intel.com>]

On Mon, 2017-03-06 at 12:29 +0100, Thomas Gleixner wrote:
> On Fri, 3 Mar 2017, Patel, Vedang wrote:
> > 
> > I now have the following concerns and comments:
> > 1. real-time kernel vs. Mainline kernel: The real-time kernel is
> > worse
> > with POSIX timers than the mainline kernel. This is odd. Is this
> > because the softirqs are not the same anymore(Sorry, I am still not
> > familiar with what they have become. I deduced the "not the same"
> > part
> > from commit messages/comments in code. :))? Also, in https://git.ke
> > rnel
> > .org/cgit/linux/kernel/git/rt/linux-stable-rt.git/commit/?h=v4.4-
> > rt&id=4aa7cba57f73acf1e3e4998ae1650965317c2de1, it is mentioned:
> > "
> > Bring back the softirq split for now, until we fixed the signal
> > delivery problem for real.
> > "
> > What signal delivery problem is being referred to?
> The problem with these timers is that the heavy lifting of signal
> processing happens in "stolen" context. That means that the work is
> not
> done in the context of the process/thread which armed the timer, but
> in
> softirq context.
> 
> What we really want here is the following:
> 
>      timer expires()
>      	   mark timer expired in thread/process
> 	   eventually wakeup thread
> 
> This is simple to achieve for timers where the signal is directed to
> a
> thread, but it's way more complex for process wide signal delivery.
> 
So, does this mean that we should be asking people not to use POSIX
timers until this is corrected? 

Also, Is there a way to specify which ktimersoftd thread (essentially
selecting a particular CPU)to use while creating a timer? Currently,
the ktimersoftd thread corresponding to the thread on which the CPU is
running is being used by cyclictest. This would prevent the bounce
between ktimersoftd and cyclictest thread when both of them are on the
same CPU. 

Thanks,
Vedang Patel
Software Engineer
Intel Corporation
> > 
> > 2. In the case the CPU affinity is set, The CPU is shared between
> > cyclictest thread and the ktimersoftd thread. So, in the end, 1 CPU
> > migration is cheaper than 3 context switches... Is this the right
> > analysis? I know this will vary from application to application.
> No, migration is not generally cheaper, in most cases its more
> expensive.
> 
> Thanks,
> 
> 	tglx