default to n for GROUP_SCHED and FAIR_GROUP_SCHED
in [Kernel]
|
From: Ingo Molnar on 5 May 2008 16:30 * Arjan van de Ven <arjan(a)infradead.org> wrote: > On Mon, 5 May 2008 20:42:35 +0200 > Ingo Molnar <mingo(a)elte.hu> wrote: > > > In practice distro maintainers will pick the upstream default 99% of > > the time, > > actually.. not quite. They don't tend to look at "default" in Kconfig; > they tend to say "m" if possible, and otherwise read the help text to > see if it makes sense... yeah, that's what i meant mostly - to new drivers we unfortunately default to 'n'. And most of the time (i hope!) our defaults for new core kernel and architectural features otherwise make sense. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 5 May 2008 16:50 On Mon, 5 May 2008, Ingo Molnar wrote: > > yeah, that's what i meant mostly - to new drivers we unfortunately > default to 'n'. And most of the time (i hope!) our defaults for new core > kernel and architectural features otherwise make sense. I doubt it. People are *way* too eager to mark things 'y', because it may make sense as a default to the developer of the feature, never mind that the average user should never *ever* enable it. There are even things that are clearly marked experimental (and depend on the EXPERIMENTAL config option), and then have the gall to say "default y". Another example of that kind of behaviour, for example, is just you fighting turning off 'default y' from FAIR_GROUP_SCHED, considering that it is known to cause latency problems and the reason isn't understood. Developers want their features to be enabled. Regardless of whether they are features that make sense to normal people. I'd love to make "default y" be something you must never do (except for question that don't get asked at all!), but that would just cause people to create negative config options ("disable my cool feature?") which we already have to some degree, and which is *really* irritating. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 5 May 2008 17:10 * Linus Torvalds <torvalds(a)linux-foundation.org> wrote: > Another example of that kind of behaviour, for example, is just you > fighting turning off 'default y' from FAIR_GROUP_SCHED, considering > that it is known to cause latency problems and the reason isn't > understood. a side-note to this topic: after looking at a bunch of traces and after a lot of testing, the latency problems are complex, but reasonably well-understood. Nevertheless we'll mark it default-disabled because it's been taking too long to create and propagate the fixes. I've queued up a patch for that. We might even mark it BROKEN for a single release so that the option disappears from people's config? Or we could change the name to achieve a similar effect. The main design-level latency source was due to the hierarchic view of group scheduling - we had a hierarchy of runqueues. CFS met the latency targets, but only per level (per runqueue) of the hierarchy. So with every new level, we got more maximum latency. So for example on a system with fair user scheduling, it takes just a couple of different UIDs to be probabilistically active at once to generate a bad latency: say if root, nobody, distcc and mingo UIDs are are active at once, the mingo task could see a 4x latency hit over the target - 160 msecs instead of 40 msecs. This is now believed to be fixed in sched-devel.git, via the "single runqueue" and deadline-scheduling patches from Peter that flattens the hierarchy of the group scheduler. Another latency source was the skew of sched_clock() running too slow - that way if the clock runs at 10% of its intended speed the scheduler will turn a 40msec intended latency target into a 400 msec latency target! This bug too is now believed to be fixed via Peter's new sched_clock code in sched-devel.git. .... and users now have a very objective stick they can use on us: latencytop. It told us black and white when we sucked. (I am waiting for the days when it will auto-create a scheduler trace for the worst latency hit in the system, making it easy for users to submit traces.) Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Parag Warudkar on 5 May 2008 17:40 On Mon, May 5, 2008 at 1:21 PM, Ingo Molnar <mingo(a)elte.hu> wrote: > does -git boot fine - or is this a regression relative to v2.6.25? > > I just built your config on latest sched-devel and booted it on two > 64-bit testboxes and it boots just fine. > > could you send your -git bootup log? Hmm - It's the IO_DELAY stuff - I will test more but it looks like with CONFIG_IO_DELAY_TYPE_NONE -git boots fine on my machine but with the same option sched-devel does not. Setting CONFIG_IO_DELAY_TYPE=0 (0x80) makes sched-devel boots again. Parag -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Parag Warudkar on 5 May 2008 17:50
On Mon, May 5, 2008 at 5:05 PM, Ingo Molnar <mingo(a)elte.hu> wrote: > > This is now believed to be fixed in sched-devel.git, via the "single > runqueue" and deadline-scheduling patches from Peter that flattens the > hierarchy of the group scheduler. > > Another latency source was the skew of sched_clock() running too slow - > that way if the clock runs at 10% of its intended speed the scheduler > will turn a 40msec intended latency target into a 400 msec latency > target! > > This bug too is now believed to be fixed via Peter's new sched_clock > code in sched-devel.git. Ok, but the latency problems are not fixed with sched-devel as of today. I still get unusable audio if I enable GROUP_SCHED stuff on sched-devel and run make -j8 . Parag -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |