[lkml]   [1998]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] scheduler patch, faster still
    Thus spake Larry McVoy (
    > Furthermore, your suggested "fix" is completely specific to your
    > application with short RT run queues. What happens if you have 10
    > RT processes? Won't they have exactly the same "problem" that you
    > are currently "fixing" by moving your processes off the run queue
    > onto another queue? If that's the case, how can you possibly call
    > it a RT queue - it only helps you. Shouldn't it really be called the
    > Short_RT_Process_Queue_For_Mr_Goochs_Possible_Problem?

    I don't understand why you are flaming him so badly.
    I don't care if it fixes his problem or not. If it looks sensible and
    actually speeds something up without slowing the common case down,
    it's a good idea to integrate it.

    One of the cornerstones of computer science is

    Make the common case fast.

    Your argumentation about long RT run queues is not a valid argument.
    The common case is clearly to have an empty RT run queue or one with one
    process (MP3 player) and people who want to do hard RT will want to use
    RTLinux, anyway. The argument that it might not help long run queues is
    like using NT because it might become more stable in a few years.

    If the effects of his optimization is not measurable for typical
    workloads, who cares? As long as it does not make the code obfuscated
    or bloated or slower in the common case, it doesn't hurt.


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

     \ /
      Last update: 2005-03-22 13:44    [W:0.020 / U:1.560 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site