[lkml]   [2004]   [Jul]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.6.X, NPTL, SCHED_FIFO and JACK
    >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

    >> 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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:04    [W:0.023 / U:7.472 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site