I've received an internal request for a means to determine at run-time
if the CFS scheduler is included in the running kernel. Looking through
the git commit log and the /proc/sys/kernel filesystem, I think I see
two approaches:
1) stat("/proc/sys/kernel/sched_compat_yield")
This confirms 2.6.23-rc7 kernel or later which definitely has the CFS
scheduler and this functionality is of interest anyway.
2) Test if the kernel version is >= 2.6.22 which is where I believe CFS
landed.
Any guesses as to how robust/future-proof approach #1 would be?
--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
On Fri, 2009-03-06 at 12:44 -0800, Darren Hart wrote:
> I've received an internal request for a means to determine at run-time
> if the CFS scheduler is included in the running kernel. Looking through
> the git commit log and the /proc/sys/kernel filesystem, I think I see
> two approaches:
>
> 1) stat("/proc/sys/kernel/sched_compat_yield")
> This confirms 2.6.23-rc7 kernel or later which definitely has the CFS
> scheduler and this functionality is of interest anyway.
> 2) Test if the kernel version is >= 2.6.22 which is where I believe CFS
> landed.
>
> Any guesses as to how robust/future-proof approach #1 would be?
The question is why? Relying on scheduler specifics outside of whatever
POSIX mandates is an application bug.
On Fri, Mar 06, 2009 at 12:44:30PM -0800, Darren Hart wrote:
> I've received an internal request for a means to determine at run-time
> if the CFS scheduler is included in the running kernel. Looking through
> the git commit log and the /proc/sys/kernel filesystem, I think I see
> two approaches:
Sounds dangerous (you are dependent on scheduler beahviour) but if it
exists you could check /proc/config.gz (or the config file in the /boot
directory)...
--
Sitsofe | http://sucs.org/~sits/
Sitsofe Wheeler wrote:
> On Fri, Mar 06, 2009 at 12:44:30PM -0800, Darren Hart wrote:
>> I've received an internal request for a means to determine at run-time
>> if the CFS scheduler is included in the running kernel. Looking through
>> the git commit log and the /proc/sys/kernel filesystem, I think I see
>> two approaches:
>
> Sounds dangerous (you are dependent on scheduler beahviour) but if it
> exists you could check /proc/config.gz (or the config file in the /boot
> directory)...
>
So I am of course in agreement with both you and Peter. In this case,
the development team of an existing product is trying to move away from
heavy use of sched_yield(), and the CFS scheduler provides some
motivation for that as the behavior of sched_yield() changed (again).
As we know, this behavior should not be depended upon, but lots of
applications do it unfortunately. So, in this case the development team
would like to move to becoming less dependent on it, but unfortunately
do not feel it is feasible to make the change unconditionally as it has
the potential to destabilize the existing installations, etc. They
would like to be able to say, use this new approach using fewer
sched_yield() calls on kernels with CFS.
I understand it isn't ideal, and I have of course provided that
feedback, but I would like to provide them with all the information I can.
Thanks,
--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
On Fri, Mar 06, 2009 at 03:01:14PM -0800, Darren Hart wrote:
>
> So I am of course in agreement with both you and Peter. In this case,
> the development team of an existing product is trying to move away from
> heavy use of sched_yield(), and the CFS scheduler provides some
Hmm. The only thing I'll say about checking kernel versions is: do some
tests/checks with the different enterprise distro kernels. I don't think
they tend to do big backports any more but if they have that kernel
version check could become tricky...
--
Sitsofe | http://sucs.org/~sits/
Sitsofe Wheeler wrote:
> On Fri, Mar 06, 2009 at 03:01:14PM -0800, Darren Hart wrote:
>> So I am of course in agreement with both you and Peter. In this case,
>> the development team of an existing product is trying to move away from
>> heavy use of sched_yield(), and the CFS scheduler provides some
>
> Hmm. The only thing I'll say about checking kernel versions is: do some
> tests/checks with the different enterprise distro kernels. I don't think
> they tend to do big backports any more but if they have that kernel
> version check could become tricky...
Right, excellent point. Regardless of how thing are right now, relying
on the kernel revision is a bad idea for this reason.
--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team