On Fri, Oct 11, 2013 at 02:03:34PM +0200, Marc Espie wrote: > - I'm trying to get a bit *less* code to load when it isn't > necessary. Knowing we're in the 'one host' situation helps. > Specifically, memory heuristics and affinity handling are > things we don't need to have on a single host, or when no > build in memory is involved. The intricate speed-factor > queues are not needed if there's no difference in speed-factors > on a cluster... Mostly done. Code is much cleaner. And probably leaner.
Something came out of the blue: forced affinity reschedules. When a path with host affinity from a former run hits the queue, the engine notices. When it comes time to schedule a job on that particular host, the path takes precedence, preempting the normal scheduling order, so that restarts should take place much much quicker now (e.g., almost as soon as the engine has them in queues). This is much better for disk/memory pressure, of course, as dpb will first try to finish its existing work directories instead of starting new stuff (of course, stuff still has to hit the queues, so dpb still has to walk enough of the tree first). > - I should interleave host init with reading up build-stats > from disks, especially in the presence of somewhat long startup > scripts... this probably means making report a bit more dynamic > so the user knows what's going on. Interleaving much better. Forced me to fix a race between the ssh master I want and... slaves which managed to bind the socket earlier than the master! would you believe ? > - haven't had time to finish chroot on localhost, still requires > manuall chroot'ing and then starting dpb... At the "works for me" stage now... but my setup has lots of symlinks that shouldn't be, and it also requires ports to be on localhost... the order of things can be better.
