11 Jul
2004
11 Jul
'04
9:24 a.m.
Arjan van de Ven <arjanv(a)redhat.com> wrote:
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.
On Sun, Jul 11, 2004 at 03:42:58AM -0700, Andrew Morton wrote:
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.
We do not
want to enable preempt for Fedora yet because it
breaks just too much stuff
What stuff? (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? 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 :(