On 3/31/15 3:13 AM, Ingo Molnar wrote:
* Peter Zijlstra <pet...@infradead.org> wrote:
On Mon, Mar 30, 2015 at 10:43:14AM +0200, Mike Galbraith wrote:
I think it would be a good thing if we can get away with it, but I
also think you could safely bet your life that somebody will
squeak.
The thing I worry most about is that squeaking only happening 5
years later :/
So lets start by keeping the sysctl thing with the very
scheduler-internal names, but all zeroes and no effect of any change -
i.e. a dead API in all but appearance. I don't think there's any
legitimate use of those, beyond debugging, as we could change the
internal implementation anymore and moot many of those flags.
So lets trigger the squeaking that way. If any complaint comes in
beyond 1-2 kernel releases then I don't think it's a regression, it
turns into a feature request ...
Sorry to be so dense but I am not clear on what is acceptable and not.
As mentioned in a previous response, these are the scheduler related
files I am aware of:
- debufs file for sched_features (/sys/kernel/debug/sched_features)
- /proc/sys/kernel/sched_domain for tweaking scheduling parameters
- /proc/sched_debug - various internal stats
- /sys/devices/system/cpu entries. e.g., for cpu topology (physical
package id, core id, sibling cores and threads)
None of them show the sched_domain information which is the subject of
this patch.
Can someone clarify on the duplication concerns and such?
Thanks,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
