[lkml]   [2003]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: 2.6 must-fix list, v2

    Quoting Zwane Mwaikambo <>:

    > Not really, during load your reserved cpu will now have to wait longer
    > for shared resources instead of helping make progress, bringing down the
    > performance of all your applications including the 'realtime' one.

    Of course you are right in the general case. But as long as one has correctly
    sized the load so that it does NOT exceed the dedicated CPUs, and one has
    reserved the right resources, then it can help the stability of the soft-
    realtime applications that are of interest to me.

    So, in my case, using dedicated raw-ish disks, pinned memory, dedicated CPUs
    and the understanding that the kernel has absolute priority over userspace (and
    so is never a worse bottleneck than usual), it all works. Also, my application
    maximises the probability of success by explictly managing the resources which
    *are* shared between the time-sensitive code and the relevant "joe-random" code.

    Can I be certain that there is no shared lock or anything else in the whole
    kernel? No, but I'm prepared to make that probabalistic tradeoff (backed via
    extensive testing) rather than have to go to hard-realtime.

    Thanks, Shaheed

    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 13:35    [W:0.022 / U:9.136 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site