Messages in this thread | | | Date | Fri, 17 Dec 1999 23:56:37 -0500 (EST) | From | Stephen Frost <> | Subject | Re: RasterMan on linux and threads |
| |
On Wed, 15 Dec 1999 raster@rasterman.com wrote:
> 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 ?
Well, is there any way you can make the threads last longer? If they're that short, I don't know if they'd be scheduled on multiple CPUs or not. The problem being I don't know how much locking has to happen to create the thread (locking where neither CPU is able to do much of anything because the kernel is playing w/ memory). If thread creation is a very small impact, then I'd guess yes. The problem as I see it w/ what you're talking about is more a question of if it's worth spawning off a new thread to do the task or just doing it in the next loop. I have no doubt that the thread will run on a seperate CPU if you're using pthread's (glibc) and it needs the CPU time. Though if it's only around for < 0.1 seconds, not sure that's enough CPU time. But then, it could start on a different CPU, not sure...
Stephen
- 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/
| |