[OE-core] [PATCH 1/1] libc-locale: split locale handling from libc recipe.

Koen Kooi koen at dominion.thruhere.net
Thu Jun 9 13:53:19 UTC 2011


Op 9 jun 2011, om 15:15 heeft Richard Purdie het volgende geschreven:

> On Thu, 2011-06-09 at 12:43 +0100, Phil Blundell wrote:
>> On Thu, 2011-06-09 at 12:29 +0100, Richard Purdie wrote:
>>> As you can see, eglibc do_package takes about 14 minutes which is about
>>> 14% of our build time. That is a long time to block pretty much all
>>> packaging activity, particularly if you have access to something with
>>> several cores. When it does complete, even on my 4 core system you see a
>>> "stampeding herd" of packaging happening on the build charts suggesting
>>> a backlog does build up.
>> 
>> Yeah, I can imagine that a backlog of packaging activity does build up.
>> The thing I'm not entirely clear on is whether this is actually causing
>> some threads to get starved of work (and hence the total build time to
>> be longer than it needs to be) or whether we're really just shifting
>> things around in the timeline without making much/any difference to the
>> overall build duration.
> 
> It will certainly be a net win on large core systems which I know of
> people running builds on as task starvation happens there. Last time I
> tested this on a 4 core I think we saw a couple of minutes improvement
> in build time so it appears beneficial there too.
> 
>>  (I'm not familiar enough with bitbake's
>> scheduler to know whether it will schedule tasks as early as possible,
>> or as late as possible, or something else.)
> 
> Roughly speaking, the default scheduler runs tasks with the most things
> depending upon them first. This means it will fill any "spare" threads
> with lower priority tasks such as packaging.
> 
>> Just as a matter of interest, are you using qemu-based locale generation
>> or the cross localedef for your measurement?  14 minutes does sound like
>> an awfully long time and I wonder whether there is anything we could do
>> in absolute terms to just speed that process up.
> 
> I'm using cross localedef. Its faster than with qemu but still slow. I'm
> very open to suggestions on how to speed it up as it does take an age.

Does cross localegen obey parallel make or does it only do a single locale at a time?

regards,

Koen



More information about the Openembedded-core mailing list