On Tue, 2006-01-17 at 18:40 -0600, Greg Woodhouse wrote: > --- Kevin Toppenberg <[EMAIL PROTECTED]> wrote: > > > Looks like the job manager is allowing each task only one > instruction > > cycle, then moves on. Since each job is identical, it seems > > reasonable that they would show a strict alternating pattern. > > > > Kevin > > it surprises me. Switching between tasks is not free, and I would > expect it to happen less often than on every step. Then again, this > may > be an optimization due to the code being identical in each case. It > would be interesting to have to separate but identical entry points > (except for the "A" and "B", of course) and see if the same thing > happens. > > Under GT.M I believe the two jobs will be separate processes, and > scheduling will be left to the Linux kernel.
[KSB] Here is a hypothesis for the processes moving in lock step. Consder that whenever each process tries to do an IO operation, the OS scheduler most likely takes away its CPU slice and gives it to the other process, which is ready to do its next IO within one CPU slice, so the CPU goes back and forth between the two processes that then appear to be in lock step. Yes, in GT.M, each M process is independly scheduled by the OS scheduler. -- Bhaskar ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
