Re: RasterMan on linux and threads

Richard Gooch (rgooch@ras.ucalgary.ca)
Fri, 17 Dec 1999 18:59:03 -0700

raster@rasterman.com writes:
> On 17 Dec, Richard Gooch scribbled:
> -> No, the scheduler gives a bonus to tasks with the same MM context
> -> (i.e. threads) being scheduled on the same CPU. IOW when deciding
> -> which task to schedule, one with the same MM context is given a small
> -> bonus. Last time I looked, the bonus was 3 timer ticks (== 3 dynamic
> -> priority levels).
> ->
> -> But it's merely a bonus (designed to improve cache affinity). It
> -> doesn't mean threads are locked to the same CPU.
>
> hmm - so if i do short bursted threads ( approx < 0.1 seconds each
> on average i guess ) will he get scheduled across spuc or be
> weighted to remain on the same cu due to MM afinity (whihc is why
> i'd use therads since they will share memeory space and MM affinity
> heavily) - so will hey get scheduled across cpu's - i asked san
> mehat about this and he sugsted tey'd end up all being scheduled on
> the same cpu - giving no speedup ?

It depends on how much other tasks have used from their timeslices.
The timeslice is 20 ticks (200 ms on x86). The deeper into a
timeslice, the lower the dynamic priority of a task.
At the beginning of it's timeslice, a task has dynamic priority 20.
Each timer tick it decrements by 1 (if it's still on the CPU), until
it reaches 0, at which point a reschedule is done.

When *all* processes on the run queue have exhausted their timeslices,
the dynamic priorities of all processes are recalculated.

Worst case, if your bursting threads have amost used up their
timeslices just before they went to sleep, they may wait 17 ticks (170
ms on x86) to get the CPU. However, if your bursting threads are
mostly idle, they will have a high dynamic priority, so most of the
time they will be scheduled immediately, or one or two ticks later.

This is the theory. Go forth and benchmark your application.

Regards,

Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca

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