On 11/01/2015 12:49 AM, Patrick Georgi wrote:
Just a note: the only reason why current Intel fares better
I didn't say Intel fares better. FSP is on my (rather long) hitlist, but that's not within the scope of this discussion.
7 min vs 20 min on empty ccache, and 2 min vs 6 min on primed ccache. Those are speedups of 2x to 3x.
Thank you for doing the measurements.
Thank you for creating the 'what-jenkins-does' make target.
Patch trains from google and other contributions to non-AGESA code gain a 2x to 3x speedup in server time, while users of AGESA can continue to contribute and work on the codebase.
... and diverge...
And that's expected. Convergence is a dream. AGESA boards use BuildOpts for configuration, and not much Kconfig/devicetree.cb, versus most other boards in the tree. Except for VX900 and sandybridge, every chipset implements its own SPD parsing routines. I can go on and on. Even within one branch, significant divergence exists, so non-divergence is a moot point.
Alex
So, if someone came to me with this problem: building all the targets is slow and this solution: get rid of a bunch of them
I'd tell them to go back for more data, because that's just not enough information.
Why's it slow? Where's the time going? How many files, on average, are part of an AGESA build vs., e.g., a newer chromebook build? How big are they? How many files do they include?
But sawing off one's leg because it hurts seems like a rushed decision.
So, what's going on here? Can we get a bit more specific about the problem, and a bit less drastic about the solution?
ron
2015-11-01 21:29 GMT+01:00 Alex G. mr.nuke.me@gmail.com:
Patch trains from google and other contributions to non-AGESA code gain a 2x to 3x speedup in server time, while users of AGESA can continue to contribute and work on the codebase.
... and diverge...
And that's expected. Convergence is a dream. AGESA boards use BuildOpts for configuration, and not much Kconfig/devicetree.cb, versus most other boards in the tree. Except for VX900 and sandybridge, every chipset implements its own SPD parsing routines. I can go on and on. Even within one branch, significant divergence exists, so non-divergence is a moot point.
So you picked three examples. Let me give several counter examples: 1. cbfs/fmap (backward and forward compatible): extended attributes, file-level compression, hashes 2. vboot2/verstage integration 3. SPI flash driver infrastructure 4. supporting build tool development (eg. Kconfig improvements, tighten lint rules) + the fallout to keep the tree compliant to the new standards.
All of these would be painful to port between code bases (and some were, see the chromeos-2013.04 branch).
Just because your three go-to items aren't as wonderful as (you claim) you'd like them to be doesn't mean that you get to inflict damage on other developers.
Patrick
* Alex G. mr.nuke.me@gmail.com [151101 21:29]:
Except for VX900 and sandybridge, every chipset implements its own SPD parsing routines.
Gee, let's keep VX900 around then, it's one of the few good examples ;)
Alex
Stefan
Alex G. wrote:
users of AGESA can continue to contribute and work on the codebase.
... and diverge...
And that's expected. Convergence is a dream.
I disagree. I think it's a goal rather than a dream.
AGESA boards use BuildOpts for configuration, and not much Kconfig/devicetree.cb
I've done a bit of work on moving BuildOpts config for IDS into Kconfig, but it's not quite ready yet. I wrote the change dry and the only test data I have available reports coreboot not working after applying it. :) Sometime..
SPD parsing routines. I can go on and on. non-divergence is a moot point.
I disagree - I think we need to work towards less divergence rather than move in a direction which is likely to create more divergence.
That's the only way to keep the codebase maintainable - which we all want. It was clear to me already when we saw the very first code from AMD that integration into our own codebase would take a while.
I don't want to remove contributed code until we've given that a real shot.
//Peter
I strongly disagree with this branching "solution". Why? Because - if building all the targets is slow - then just don't build all the targets at once! If you need a fast build and you are not concerned about AMD boards - just because you don't have any - it is always possible to skip AGESA build without moving it to a branch and separating from the rest of the coreboot code . So this is seen as a really bad excuse
Best regards, Vladimir Shipovalov
On 3 November 2015 at 01:14, Peter Stuge peter@stuge.se wrote:
Alex G. wrote:
users of AGESA can continue to contribute and work on the codebase.
... and diverge...
And that's expected. Convergence is a dream.
I disagree. I think it's a goal rather than a dream.
AGESA boards use BuildOpts for configuration, and not much Kconfig/devicetree.cb
I've done a bit of work on moving BuildOpts config for IDS into Kconfig, but it's not quite ready yet. I wrote the change dry and the only test data I have available reports coreboot not working after applying it. :) Sometime..
SPD parsing routines. I can go on and on. non-divergence is a moot point.
I disagree - I think we need to work towards less divergence rather than move in a direction which is likely to create more divergence.
That's the only way to keep the codebase maintainable - which we all want. It was clear to me already when we saw the very first code from AMD that integration into our own codebase would take a while.
I don't want to remove contributed code until we've given that a real shot.
//Peter
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-
Alex G. -
Patrick Georgi -
Peter Stuge -
ron minnich -
Stefan Reinauer -
Vladimir