Author: Tom Kerrigan
Date: 11:14:51 10/07/03
Go up one level in this thread
On October 06, 2003 at 09:56:59, Robert Hyatt wrote: >On October 06, 2003 at 06:15:58, Tom Kerrigan wrote: > >>On October 04, 2003 at 23:54:43, Jeremiah Penery wrote: >> >>>On October 04, 2003 at 22:27:45, Tom Kerrigan wrote: >>> >>>>You're right, the #s do work out pretty well, but that must mean both threads >>>>are bouncing around different logical processors frequently, otherwise there'd >>>>be a disparity in the node counts of each thread. This doesn't seem likely to me >>>>but I guess it's not impossible. I wonder if there's a way to keep track of >>>>which thread is running on which processor. >>> >>>The threads really do hop around the processors. You wrote previously that a >>>process should stay on the same processor until 'something odd happens' - in >>>other words, until something pre-empts the process. It's very frequent that a >>>part of the kernel, or a service, or something else with default high+ priority >>>gets scheduled for some miniscule fraction of time, so it will bump your process >>>to another processor. If you raise your program's priority to realtime and run >>>two threads, you should be able to get more stable results in this regard. >> >>Wouldn't this result in a lot of cache thrashing that would slow the program >>down? If I run two copies of my program simultaneously they each run exactly as >>fast as one copy. (Which is interesting because both copies use hash tables--I >>suppose the hash table probes are infrequent enough to not cause many FSB >>collisions.) >> >>-Tom > > >There are multiple issues. The APIC chooses which CPU to send an >interrupt to (it appears to send all interrupts to CPU#0 on my dual >2.8 running 2.4.21 linux.) An interrupt is definitely going to dislodge >a process for a brief period of time. What do you mean by "dislodge"? Push it onto the other processor? Because this must take some amount of work. Whatever schedulers are running on each processor have to communicate with each other about which processes to stop/start. Why move it to the other processor anyway? Something is likely already running on that processor so by the time the process gets a timeslice, it might as well have just waited for the stupid interrupt to be handled anyway. So maybe this is what happens and there's a good reason for it that I don't know about but right now what you're suggesting sounds like it's more work for no gain. -Tom
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.