On Mon, Nov 26, 2012 at 12:49:31PM +0100, Martin Jansa wrote: > Hi, > > my patches for mixing different -mtune params while building shared > binary feeds were merged to openembedded-core today. > > The change is only in master and wont be backported to danny branches so > current shr feeds won't be affected for some time (probably till next OE > release). But we have to decide this for shr and jansa/test branches > which tracks oe-core master. > > For more information see: > https://bugzilla.yoctoproject.org/show_bug.cgi?id=3219 > > Short example for our use case: > > nokia900.conf is using tune-cortexa8.inc which adds -mtune=cortex-a8 > tuna.conf is now using tune-cortexa8.inc, but should use > tune-cortexa8.inc which adds -mtune=cortex-a9 > > Without those patches both MACHINEs would build binary packages in > armv7a-nofvp-neon feed so some packages there would be built with > -mtune=cortex-a8 and some with -mtune=cortex-a9, which isn't fatal, > but also not really optimal. > > What's worse is that with OEBasicHash they are all rebuilt after > each MACHINE switch from nokia900 to tuna. > > End user on target (with opkg) cannot distinguish between those two, so > opkg does not upgrade/reinstall anything when binary with better -mtune > gets available in feed. > > With those patches both MACHINEs can include different tune-cortexa*, > but by default both will build without any -mtune param so > armv7a-nofvp-neon is consistent, but with a bit worse performance on > target. > > We have 4 options now: > 1) keep default, build without -mtune > + all armv7a packages are built just once > + less disk space for feed > - worse performance on target > > 2) To get -mtune back we can set more specific DEFAULTTUNE for all SHR > supported devices in distro config, so that binary feed will be renamed > from armv7a-novfp-neon to cortexa8-novfp-neon and cortexa9-novfp-neon. > + "better" performance on tuna, same on nokia900, om-gta04, crespo > - extra disk space needed for separate cortexa9-novfp-neon feed > (armv7a-novfp-neon will be removed - replaced by cortexa8-novfp-neon) > - 33% longer build time for all SHR supported machines (3 package archs > instead of 2) > > 3) set more specific DEFAULTTUNE but keep cortexa8 include in tuna > + same performance as now > + same disk space usage > > 4) implement OPTDEFAULTTUNE in distro, my first version of this patchset > added extra variable to tune files called OPTDEFAULTTUNE, so that > e.g. tune-cortexa8.inc had OPTDEFAULTTUNE = "cortexa8" and > DEFAULTTUNE = "armv7a" and then you could define per package or > per machine if you prefer to share feed (DEFAULTTUNE) or optimize > feed with -mtune (OPTDEFAULTTUNE) > Unfortunattely this version of patch was rejected, as too complex > for already complicated arm tunes. I can try to send it again now > when the rest of patches is merged. > > I don't have strong opinion on any option we have now.
I've finally finished testing different DEFAUTTUNEs for tuna MACHINE First I've read comparison of different machines from Marcin http://marcin.juszkiewicz.com.pl/2012/11/28/lets-compare-some-cpu/ And here it's extended with data from om-gta02 with 2 possible DEFAULTTUNEs and then tuna with 10 DEFAULTTUNEs: https://docs.google.com/spreadsheet/ccc?key=0Avaa_xKWksbWdDBoWjU2LU1FTVFiZDJuZTlGNkgzcFE Interesting points for us are: 1) thumb saves about 2MB (10%) from small 20MB core-image-minimal. 2) default DEFAULTTUNE from oe-core armv7a-neon is quite close to cortexa* variants (SHR is using cortexa8t-neon for all armv7a MACHINEs when meta-shr/conf/distro/include/defaulttunes.inc is included) 3) cortexa8-neon (default before DEFAULTTUNE chanegs in oe-core) and cortexa9-neon are almost the same and in most cases probably not worth it to create separate binary feed when you build also cortexa8 machines. 4) tuna is way faster then om-gta02, but everybody expected that :). > Oficial buildhost is now building from danny branches, so not influenced > by this. > > Next oe-core release will require use of PR server and that makes > OEBasicHash mandatory, so tracking master as close as we did now won't > be possible on current infrastructure we have anyway. > > Please vote on options :). > > CCing [email protected] as we will have to > discuss the same problem when we decide to upgrade oe-core again. > > Cheers, > > -- > Martin 'JaMa' Jansa jabber: [email protected] -- Martin 'JaMa' Jansa jabber: [email protected]
signature.asc
Description: Digital signature
_______________________________________________ Shr-devel mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-devel
