Date: Mon, 03 Jun 2002 18:33:57 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Kris Kennaway <kris@obsecurity.org> Cc: arch@FreeBSD.ORG Subject: Re: Removing wait union Message-ID: <3CFC1905.BF824FF3@mindspring.com> References: <20020602010108.B16166@espresso.q9media.com> <20020603011903.Y2566-100000@gamplex.bde.org> <20020603162508.A34224@xor.obsecurity.org> <3CFC00A9.BD98B7BD@mindspring.com> <20020603181537.A37707@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway wrote: > > I think the problem needs something other than the ports cluster. > > > > The ports cluster is designed to keep dependencies seperate, so it > > serializes a lot of things that could otherwise be done in parallel, > > to ensure dependency order is maintained. > > In practise this isn't an issue. I haven't obtained accurate > statistics, but the cluster runs at full capacity for pretty much the > entire build. You need to keep statistics of how many times each individual port is built, in the cluster case (i.e. you need a combinatoric dependency map and a way to factor out permutations that are necessary for solving the ports problem, but not necessary for solving the "what breaks?" problem). When you build a given port on its own little virtual box, you also build all the ports on which it depends. This is by design, since it avoid the problem of finding dependencies which are not explicitly called out. In the case of a system change, you aren't concerned about that; in fact, you *want* it to happen, since it reduces the total build time. How many machines are in the ports cluster? Knowing how many total cycles are required, and how many redundant dependency builds happen, would be a good way to ballpark whether it's feasible to build a single machine that can tell what is broken by a proposed base OS change, before the change is checked in. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CFC1905.BF824FF3>