Am 26.11.2012 20:25, schrieb Martin Jansa: > On Mon, Nov 26, 2012 at 08:10:11PM +0100, Denis 'GNUtoo' Carikli wrote: >> On Mon, 26 Nov 2012 12:49:31 +0100 >> Martin Jansa <martin.ja...@gmail.com> wrote: >> >>> 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) >> I think that's the way to go but I've some comments on that: >> * SHR does support tuna? I don't think it's well supported since no >> one is working on it for SHR. > > It's built on official buildhost so from this POV it's supported and it > has more atention then e.g. nokia900 and crespo.. > >> * SHR hasn't got a very powerfull buildhost, so we could skip building >> tuna on the official SHR buildhost until someone steps in and >> supports it? > > SHR buildhost is using danny branches, so not problem now. The problem > is for devs using shr or jansa/test branches and building tuna together > with other armv7a devices just because it's almost "for free" as it > reuses whole feed and sstate-cache. > >> * Openwebos supports tuna and has a powerfull buildhost. does it have >> cortex a8 machines? the HP touchpad? > > Powerfull buildhost is not yet in use and tuna is the only armv7a > device built by webos-ports jenkins (at last now), so no problem here. > >> So I think we could do 2) in a way that won't impact build a lot. > > would be nice to have some benchmarks to see how much (if anything at > all) we gain by using -mtune and especially -mtune=cortexa8/a9 diff. > > FWIW: I can already provide SHR images for tuna/nokia900/om-gta02 built > without > -mtune.
Benchmarks seem to be a good idea. If it is of real benefit I'd vote for (2) as well, as that is what we have OE for – device specific optimization. If we'd just use "generic" package architecture, we'd probably be better of using Debian as a base, which already provides this. If there is no performance win, though, we should choose the option which our buildhost can provide, so we'd have one problem less: search a new/better buildhost. Cheers, Lukas
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Shr-devel mailing list Shr-devel@lists.shr-project.org http://lists.shr-project.org/mailman/listinfo/shr-devel
