[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49B1AB3A.2050303@us.ibm.com>
Date: Fri, 06 Mar 2009 15:01:14 -0800
From: Darren Hart <dvhltc@...ibm.com>
To: Sitsofe Wheeler <sitsofe@...oo.com>
CC: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...e.hu>,
"lkml, " <linux-kernel@...r.kernel.org>
Subject: Re: Dynamically determine if kernel includes CFS Scheduler
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists