Re: [announce] [patch] Voluntary Kernel Preemption Patch

[Andrew Morton]

Arjan van de Ven <arjanv@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/