lkml.org 
[lkml]   [2002]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [patch] O(1) scheduler, -D1, 2.5.2-pre9, 2.4.17
Date
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>

-Ryan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:15    [from the cache]
©2003-2011 Jasper Spaans