Re: RasterMan on linux and threads
Richard Gooch (rgooch@ras.ucalgary.ca)
Fri, 17 Dec 1999 15:18:35 -0700
raster@rasterman.com writes:
> ->
> ->
> -> On Fri, Dec 17, 1999 at 09:53:38AM +0100, Borek Lupomesky wrote:
> -> > -----BEGIN PGP SIGNED MESSAGE-----
> -> > Hash: SHA1
> -> >
> -> > On Fri, 17 Dec 1999 jgarzik@mandrakesoft.com wrote:
> -> >
> -> > > Also threads right now under linux all run on the same processor so
> -> > > under linux there is NO speed advantage to threads. You just end up
> -> >
> -> > Is it really so?
> ->
> -> Nope. He just doesn't know anything about scheduling (or threading).
>
> actually - u'd be surprised. i spent many years writing my own
> scheduling in 68k asm on he amiga (first sys call was forbid(); last
> one before exitign as permit(); - inside that time i took over the
> system and thus if i anted processes or threads i had to do them
> myseufl). my unerstanding as the kernel scheduled threads on the
> same processor to retain cache coherency for more efficiency - so
> you have a process that's just memeory/numeber crunching it doesn't
> help much in that case - you just spend time context switching and
> you dont take advantage of idle cpu.
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.
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/