[linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch
From: Andrew Morton (akpm_AT_osdl.org)
Date: Sun Jul 11 2004 - 14:13:29 EEST


Arjan van de Ven <arjanv_AT_redhat.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 :(


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sun Jul 11 2004 - 14:18:40 EEST