|| ||Andrew Morton <akpm-AT-osdl.org>|
|| ||Arjan van de Ven <arjanv-AT-redhat.com>|
|| ||Re: [announce] [patch] Voluntary Kernel Preemption Patch|
|| ||Sun, 11 Jul 2004 04:13:29 -0700|
|| ||mingo-AT-elte.hu, linux-kernel-AT-vger.kernel.org,
Arjan van de Ven <email@example.com> wrote:
> On Sun, Jul 11, 2004 at 03:42:58AM -0700, Andrew Morton wrote:
> > > We do not want to enable preempt for Fedora yet because it
> > > breaks just too much stuff
> > What stuff?
> just look over all the "fix preempt" stuff that got added to the kernel in
> the last 6 months. Sometimes subtle sometimes less so. From a distribution
> POV I don't want a potential slew of basically impossible to reproduce
> problems, especially this young in 2.6, there are plenty of other problems
> already (and before you ask "which", just look at how many bugs got fixed in
> the last X weeks for any value of X, and look at say acpi issues).
> Yes I understand this puts you into a bit of a bad position, several distros
> not enabling preempt means that it gets less testing than it should.
> However.. there's only so much issues distros can take and with 2.6 still
> quite fresh...
IOW: "we haven't found any such stuff". Sounds fuddy to me.
> > > (Long-term i'd like to see preempt be used unconditionally - at which
> > > point the 10-line CONFIG_VOLUNTARY_PREEMPT Kconfig and kernel.h change
> > > could go away.)
> > And "stuff" is already broken on SMP, yes?
> That's the classic preempt "myth"; it's true if you ignore per cpu stuff and
> some other subtle issues ;)
Sticking a WARN_ON(!in_atomic()) if CONFIG_PREEMPT into smp_processor_id()
should catch any missed fixes.
> And even then, yes a lot of our drivers are not
> quite SMP safe. Take ISDN or any of the other declared SMP-broken drivers.
> Not to speak of the ones that aren't declared as such yet still are.
> Regardless of Hyperthreading, smp is still quite rare while crappy
> hardware/drivers are not.
Oh I can buy the make-the-bugs-less-probable practical argument, but
sheesh. If you insist on going this way we can stick the patch in after
2.7 has forked. I spose. The patch will actually slow the rate of
improvement of the kernel :(
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
to post comments)