On 15 Apr 2004, Dan Kegel <[EMAIL PROTECTED]> wrote:
Martin Pool wrote:
1. Since the list of hosts read from $prefix/etc/distcc/hosts is the same for all workstations, every workstation will issue large compile jobs to itself sometimes even though it'd be better off only handling preprocessing and linking (right?)
Linking counts against jobs running on the local machine too. If it's linking in parallel with compiling then it should try to do the compiles remotely.
Ah, so it notices that "localhost" is the same machine as "zytor" when running on zytor?
No, it won't do that.
Then perhaps I should submit a patch to add that, so it won't try sending jobs to itself by accident?
I'm not sure then. Maybe you should have different hosts files for each machine to randomize theorder.
Or perhaps add an option to the client for it to randomize the list of hosts when it first reads it in. (Maybe a flag in the hosts list?)
If the workstations have a reasonable amount of memory then running a couple of low-priority daemons should not hurt too much. Remember it will only accept about 2*NCPUS.
Yes, but that means the compile jobs (which could run faster on some other compile server which is ready and waiting) will execute slower.
Yes.
Right, I should be able to measure that in an appropriate stress benchmark, then.
We could check the load average before accepting jobs but that is actually a pretty poor measure for modern machines.
Oh, I dunno, the number of processes in 'R' state seems like it'd be a pretty good measure of load if there's plenty of RAM and the distcc job wouldn't cause any disk I/O. Or the number of processes in 'R' or 'D' state if jobs do tend to do disk I/O, maybe.
One problem is that load average responds pretty slowly to changing state. It might still be worth trying though.
I can get the instantaneous runqueue length, but that's not the greatest, either. I'll have to poke around to see what's available. (I *would* like this to work well on both MacOSX and Linux, but I'm not much of a MacOSX hacker, and getting it right for even one OS would be a big win.) - Dan
--
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change
__ distcc mailing list http://distcc.samba.org/
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc
