[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090817090319.20979986@nehalam>
Date: Mon, 17 Aug 2009 09:03:19 -0700
From: Stephen Hemminger <shemminger@...tta.com>
To: john stultz <johnstul@...ibm.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
linux-kernel@...r.kernel.org
Subject: clocksource changes in 2.6.31 - possible regression
The following commit causes a change for kernels built with HRT but
not actually using HRT. I typically use the generic kernel we ship
on test machines, and that kernel has NOHZ and HRT (for power savings/virt
and HRT for QoS), but I want to be able to enable TSC as a clock source
when doing performance tests with pktgen.
The machine in question is a several year old Opteron box, that
normally reports clocksources: acpi_pm jiffies tsc
but now with 2.6.31-rc6, it only has acpi_pm.
Since HRT/NOHZ is not really runtime configurable, I think the
proper behavior is:
* kernel reports all possible clocksources and chooses the best
by default
* if user demands a different clocksource, the kernel should use that
but degrade if necessary: ie. high-res timers have less (maybe even
only HZ accuracy), and nohz should be automatically disabled if
needed
commit 3f68535adad8dd89499505a65fb25d0e02d118cc
Author: john stultz <johnstul@...ibm.com>
Date: Wed Jan 21 22:53:22 2009 -0700
clocksource: sanity check sysfs clocksource changes
Thomas, Andrew and Ingo pointed out that we don't have any safety checks
in the clocksource sysfs entries to make sure sysadmins don't try to
change the clocksource to a non high-res timer capable clocksource (such
as jiffies) when high-res timers (HRT) is enabled. Doing so will likely
hang a system.
Correct this by filtering non HRT clocksources from available_clocksources
and not accepting non HRT clocksources with HRT enabled.
Signed-off-by: John Stultz <johnstul@...ibm.com>
Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
--
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