From owner-freebsd-arch Mon Jun 3 18:34:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id AFD9C37B408 for ; Mon, 3 Jun 2002 18:34:40 -0700 (PDT) Received: from pool0469.cvx22-bradley.dialup.earthlink.net ([209.179.199.214] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 17F3DW-00057Q-00; Mon, 03 Jun 2002 18:34:35 -0700 Message-ID: <3CFC1905.BF824FF3@mindspring.com> Date: Mon, 03 Jun 2002 18:33:57 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kris Kennaway Cc: arch@FreeBSD.ORG Subject: Re: Removing wait union 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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