On Fri, Jun 30, 2006 at 12:12:10PM +0200, Adam Borowski wrote: > On Fri, Jun 30, 2006 at 03:26:15AM +0200, Goswin von Brederlow wrote: > > Adam Borowski <[EMAIL PROTECTED]> writes: > > > Still, the buildd admin has no way to estimate how much a sub-process > > > of a package is going to use, the maintainer has at least a rough > > > idea. Since the maintainer's action is needed anyway, he can as well > > > provide this estimate. > > > And then the buildd admin can set CONCURRENCY_LEVEL to 1 to centrally > > > disable any parallelism of this kind. > > > > One could patch make to use concurency when the ram permits. This > > would involves checking the current ram usage and forking more builds > > if there is enough > > Oh, so you mean checking the _free_ RAM instead of the _physical_ RAM? > This would be reasonable
Not at all. It's not as if "the amount of free RAM" is a variable that is static throughout a machine's usage. If something else is being done on the machine in question, then whatever happens to be the amount of free RAM available at the time the test is ran doesn't have to be the amount of free RAM available at the time the most RAM is in use during the build. Additionally, it puzzles me how you think a maintainer will be able to accurately predict how much RAM a certain build is going to use. There are so many variables, that I think anything but 'this is the fastest way to build it on my machine' is going to be unfeasible. And since that's hardly useful... Have you thought about that? -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]