Re: Regression on rt kernel while using POSIX timers

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

Hi Thomas, 

Thanks for all your input.

On Tue, 2017-03-07 at 18:03 +0100, Thomas Gleixner wrote:
> On Tue, 7 Mar 2017, Patel, Vedang wrote:
> > 
> > On Mon, 2017-03-06 at 12:29 +0100, Thomas Gleixner wrote:
> > 
> > > 
> > > 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?
> Well, we always recommended clock_nanosleep() to be used and to avoid
> signal based timers when ever possible.

I have 2 questions:

1. I see a regression for POSIX timers on real-time kernel from the
mainline kernel for the kernel versions I am using. Has anyone else
seen this? I have tested multiple kernels (4.1, 4.4, 4.9.4) and I am
seeing a regression in all of those. Is this something we expect
because of changes in softirqs?

2. If there is indeed a regression, what is the best way to document
this? I think posting results on https://wiki.linuxfoundation.org/realt
ime/documentation/howto/tools/cyclictest and pointing out regressions
will be one way.

Thanks,
Vedang

> 
> > 
> > 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.
> Nope. This is even more complex than you describe it and no, we
> definitely
> don't want to think about this in the first place.
> 
> Thanks,
> 
> 	tglx
>