[lkml]   [2002]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] O(1) scheduler, -D1, 2.5.2-pre9, 2.4.17
    On January 9, 2002 03:19, Rene Rebe wrote:
    > Could someone tell a non-kernel-hacker why this benchmark is nearly
    > twice as fast when running reniced??? Shouldn't it be slower when it
    > runs with lower priority (And you execute / type some commands during
    > it)?

    In addition for using the nice level as a priority hint, the new scheduler
    also uses it as a hint of how "CPU-bound" a process it. Negative (higher
    priority) nice levels give the process short, frequent timeslices. Positive
    priorities give the process long, infrequent time slices. On an otherwise
    (mostly) idle system, both processes will get the same amount of CPU time,
    but distributed in a different way.

    In applications that really don't care about interactivity, the long time
    slice will increase their efficency greatly. In addition to having a fewer
    context switches (and therefore less context switch overhead), the longer
    time slices give them more time to warm up the cache. This has been referred
    to as "batching", as the process is executing at once what would normally
    take many shorter timeslices to complete.

    So, what you're actually seeing is the reniced task not taking up more CPU
    time (it's probably actually using slightly less), just using the CPU time
    more efficently.

    <worships Ingo>

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