Re: Detecting PREEMPT_RT

[Michael Haberler <mail17@mah.priv.at>]

Am 21.01.2013 um 13:17 schrieb John Kacur:

> On Mon, Jan 21, 2013 at 1:14 PM, Michael Haberler <mail17@mah.priv.at> wrote:
>> John,
>> 
>> 
>> Am 21.01.2013 um 12:36 schrieb John Kacur:
>> 
>>> On Sun, Jan 20, 2013 at 9:18 PM, Carsten Emde <C.Emde@osadl.org> wrote:
>>>> John,
>>>> 
>>>> 
>>>>>>>> Unfortunately, this wiki article is old and unmaintained. You're
>>>>>>>> probably right to be a bit suspicious when checking for the "-rt"
>>>>>>>> suffix
>>>>>>>> of the kernel release (uname -r). But looking for the occurrence of
>>>>>>>> "PREEMPT RT" in the kernel version (uname -v) should work. An
>>>>>>>> application may use the system call uname() and check the version
>>>>>>>> element of the utsname structure.
>>>>>>> 
>>>>>>> the utsname.version string match is fine, however:
>>>>>>>> 
>>>>>>>> In addition you may want to make sure the system has
>>>>>>>> high-resolution
>>>>>>> 
>>>>>>> timers. If so, the timers in /proc/timer_list have ".resolution: 1
>>>>>>> nsecs". An application may use the function check_timer() from
>>>>>>> cyclictest for this purpose:
>>>>>>>> 
>>>>>>>> static int check_timer(void)
>>>>>>>> {
>>>>>>>>  struct timespec ts;
>>>>>>>> 
>>>>>>>>  if (clock_getres(CLOCK_MONOTONIC, &ts))
>>>>>>>>    return 1;
>>>>>>>> 
>>>>>>>>  return (ts.tv_sec != 0 || ts.tv_nsec != 1);
>>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> Just tried this on a generic kernel (2.6.32-45-generic #102-Ubuntu
>>>>>>> SMP Wed Jan 2 21:53:06 UTC 2013 i686 GNU/Linux) and I get ts.tv_sec == 0
>>>>>>> and ts.tv_nsec == 1, so it looks this cant be used to tell an RT_PREEMPT
>>>>>>> from a vanilla kernel
>>>>>> 
>>>>>> I meant boolean AND when I said "In addition".
>>>>> 
>>>>> Oh, I interpreted the timer check not as a PREEMPT_RT check, but a
>>>>> separate check for timers, which we must confirm are available before
>>>>> driving heavy machinery.
>>>>> So, if utsname.version contains "PREEMPT RT", then load the preempt-rt
>>>>> module.  Once the module is loaded, from an init() function, run sanity
>>>>> checks, including the clock_getres check above.  Is that about right?
>>>> 
>>>> Yes. Sounds good to me.
>>>> 
>>> Note we added a patch, called sysfs-realtime-entry.patch, but I'm not
>>> sure how far back it goes, at least it's in 3.x-rt kernels.
>>> 
>>> This is the text from the patch
>>> 
>>> "Add a /sys/kernel entry to indicate that the kernel is a
>>> realtime kernel.
>> 
>> found this: https://bugzilla.redhat.com/show_bug.cgi?id=728551 and this:
>> https://github.com/clrkwllms/rt-linux/commit/274ca2cb72e013602cebb8dc142a7c69d42f92db
>> 
>> looks like it is being used elsewhere: http://softballinfo.net/ret/root/usr/lib/python2.6/site-packages/sos/plugins/kernel_realtime.py
>> 
>>> 
>>> Clark says that he needs this for udev rules, udev needs to evaluate
>>> if its a PREEMPT_RT kernel a few thousand times and parsing uname
>>> output is too slow or so.
>>> 
>>> Are there better solutions? Should it exist and return 0 on !-rt?"
>>> 
>>> To use it, you do something like
>>> test -e /sys/kernel/realtime
>> 
>> excellent - this works fine for me (I dont see us going back further than 3.4):
>> 
>> mah@atom:~$ uname -a
>> Linux atom 3.4.13-rt-preempt-rt22+ #2 SMP PREEMPT RT Fri Oct 19 08:56:20 CEST 2012 i686 GNU/Linux
>> 
>> mah@atom:~$ ls -l /sys/kernel/realtime
>> -r--r--r-- 1 root root 4096 2013-01-21 12:53 /sys/kernel/realtime
>> 
>> mah@atom:~$ cat /sys/kernel/realtime
>> 1
>> 
>> The way I read it the fingerprint is - '/sys/kernel/realtime' exists and contents is '1'
>> 
>> thanks a lot!
>> 
> 
> No problem, now if you want to give back, please feel free to update
> the wiki as well!


https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO#Runtime_detection_of_an_RT-PREEMPT_Kernel

- Michael