Re: 2.6.X, NPTL, SCHED_FIFO and JACK

[Paul Davis]

>Not only are lowlat-alike changes in mainline 2.6, the algorithms where
>lowlat found explicit preemption points were necessary have been changed
>in a number of cases to be asymptotically faster.

*Some* of the algorithms. 

>So you gave no feedback. What do you expect us to do? There are

Actually, the linux audio community gave quite a lot of feedback early
in the life of 2.5, most of it directly to andrew, ingo and robert
(love). The situation wasn't good at all. It wasn't all the scheduler
(although that was pretty bad) and explicit preemption (which was
basically missing inspite of the preemption patch) - the VM system was
hosed for massive disk streaming, for example - and the feedback we
got, while sympathetic, was basically of the form "2.{5,6} isn't going
to the lowlat route, please wait and see what we come up with". So we
waited.

>> about similar issues in 2.5 before it was even half-done. I tested
>> just about every MM patch from andrea and rik that came out for
>> 2.3/2.4 - I did not have time to do that with 2.5.
>
>This level of participation is by no means a requirement. Just show

Given my sporadic observations of the kernel mailing list over the
last five years, I'd say that it often is a requirement, especially if
you are dealing with workloads and application behaviour that is
fundamentally different to the usual "linux stuff" and cannot be
reduced to simple test cases. And I've been happy to provide it when
there is some indication that the resulting feedback will make a
difference. Andrea, Ingo and Andrew all provided that sense of purpose
for 2.4.

>The thing that went wrong here is that the report is very non-specific.

We don't have anything very specific to report. Sometimes, the most
helpful bug reports start life as someone asking "this doesn't seem to
work very well under conditions X, Y but its OK with Z". Someone turns
around and says "oh, duh!" and the problem is fixed. Apparently, in
this situation, that may not be the case. No problem. We'll come back
with more specifics.

>really the way things are supposed to work. Narrowing the presumed
>kernel issue down to a small enough userspace testcase or section of
>code that you can reasonably post it is pretty much a burden you should
>have taken on.

And I/we're willing to do that (and have been doing that) once its
clear that this is the right path.

>For one, the description of the nasty kludges or code that worked in
>2.4 but not 2.6 should have been up-front. e.g. "I'm trying to get an

There were *no* nasty kludges in JACK for 2.4 unless you refer to a
technique recommended by many *nix programming books and wizards over
the last 20 years to deal with the rather limited security model that
Linux was offering in 2.4 along with its POSIX cousins. And I note in
passing that as within a week or two of us discovering the security
module system in 2.6, someone in the audio community immediately wrote
a very nice kernel module to remove the need for jackstart.

It would also be nice if you could at least implicitly acknowledge
that the one of the major reasons (mvista being the other) that the
latency performance of linux has improved in the last 4 years is
because us RT audio guys have done such nasty, fucked up, useless,
pathetic job of requesting and collaborating on efforts to improve
it. The preemption patch came from a different direction, and didn't
accomplish the same thing - hardly anyone on the kernel list seemed to
care that the kernel was filled with 50ms interrupt masks until we
started explaining how it made linux unusable for certain things that
worked OK on windows + macos; this then led to many of us helping ingo
and andrew in their incredible attempts to fix things.

That doesn't let us off the hook of decent bug reporting, but if you
could at least quit the adult-lecturing-recalcitrant-adolescent tone,
there would be more useful exchanges going on.

--p
-
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/