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 > ��.n��������+%������w��{.n�����{�����ǫ���ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
