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.
-> Moving a thread to a different processor is almost always a loss in
-> the real world (ie except for very long-lived threads with one thread
-> per proc on an otherwise idle box), because it means that not only do
-> you have the cost of migrating the process to the other processor, but
-> you lose cache-affinity (you need to save and restore as much context
-> as seperate processes whereas if they share a processor, all the
-> process data is in the processor cache for all threads to share
-> without cache misses). It also means that other processes suffer,
-> because your one multi-threaded process (in the case of 2-way SMP)
-> would get twice as many context switches (each thread would need to
that'd be a good thing - it'd be exatly what i'd want - starve the
machine or a short period and get the job done faster then leave the
system alone sooner - when it coems to graphics getting the job done as
fast as possible is more important - it's like handling interrupts -
take too long and you'll miss packets on the wire or have hardware
problems. with gfx the effect is the new display takes longer to come up
and be all there - the rendering is often done in short bursts to get
the screen's displalinux-kernel@vger.rutgers.eduy all done then the processing ceases and the user
gets to see the result.
-> get swapped in and out seperately per processor), and introduces lots
-> of luvverly atomicity nasties, because process data (visible to all
thats why i'm not touching it yet - i just don't want to deal witj that
hadache again... i'e done it before and its just painful - you always
make that silly mistake or overlook something - i'm not going to start
writing theraded code unless i actually could expect (given very well
ordered code so threads dont wast too much time spinning in wait loops)
a very good speedup on SMP machines (UP boxes wont see any benefit - so
it woudlnt spawn treads ona UP box - it would spawn as many as you have
cpu's on smp machines)
-> threads) needs to be available to all processors. Summary: Ouch.
my premise that was based on information form someone who has ben hacki
gn at kernels and ootloders for a few years and thus i made an
assumtion is corrent sicne they proted a kernel to a new architecture.
i actally thought they wree on separate cpus until i heard this - thats
why i originally considered threaded rendering code - but now i have
conflicting information. assuming threads froma single process dont
span multpile cpu's, thus it would be useless for imlib2 (the context
i'm talking about) since they spend no time in the internal loop i'm
considering threads for, in any blocking function calls - its all
number munching and memory bashing... so it woudl just pause a crrent
number crush and do another - if anything losing performance.
-> The benefit of threading comes from the fact that things can be done
-> while parts of your process are blocked waiting for other things to
-> happen. You can do processing while blocked on a socket waiting for
-> connections for example. Remember also that your process is constantly
-> being scheduled on a processor and dropped. Multi-threaded processes
-> have "more bites of the cherry" when it comes to scheduling, even on
-> UP.
->
-> He would do well to remember the words of Dan Bernstein: "Don't
-> speculate- benchmark".
how about "examine the thery first before spending time on impirical
code that wont do anything useful". scientists often examine theory
first before performing experiments and tr to see what theory woudl
predict. i was basing that on the information orm mr mehat that threads
onyl get scheduled on one cpu (threads from one process) - in whihc
case they would be completely useless to me.
--
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler) raster@rasterman.com raster@valinux.com
raster@enlightenment.org raster@linux.com
raster@zip.com.au
-
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/