Opportunity for speedup

Gary C Martin gary at garycmartin.com
Sun Mar 1 18:40:57 EST 2009

On 1 Mar 2009, at 21:44, Bobby Powers wrote:

> I've fixed a few issues, packaged up bootanim-2.3-1, and (finally)
> actually ran some benchmarks.  Results (all times in seconds):
> fresh os801, from pressing the power button to appearance of sugar's
> prompt for name screen
> 80
> 79
> 78
> with rhgb-client renamed so that init can't find it:
> 69
> 68
> and with bootanim-2.(1-3) rpm installed:
> 67
> 67
> 67
> 68
> 67
> If anyone is unconvinced, I could run more tests, but this seems
> pretty good to me.  Its a 15% overall speedup in the boot process.

Hey Bobby, that sounds great, many thanks for putting the effort in!  
I'll try your rpm on one of the XOs here and ping back with some  
additional measurements.


> Interesting notes:
> chkconfig doesn't like binary services - it parses services in
> /etc/init.d to look for metadata in comments, and the mechanism to
> override this data (sticking a file with the same name in
> /etc/chkconfig.d with appropriate comments) doesn't seem to work if
> the original script can't be parsed.  So I had to make small wrappers
> for ul-warning, boot-anim-start and boot-anim-stop.  This doesn't seem
> to affect performance.
> I can't seem to get ul-warning to come up properly, so if anyone can
> tell me what I'm doing wrong that would be great.  I've got it to work
> by manually placing some symlinks in /etc/rc0.d and /etc/rc6.d, but
> neither Scott's nor my chkconfig comments seem to work.
> source:
> http://dev.laptop.org/git?p=users/bobbyp/bootanim
> koji-built rpms:
> http://dev.laptop.org/~bobbyp/bootanim/
> (koji task https://koji.fedoraproject.org/koji/taskinfo? 
> taskID=1211738 )
> I don't know if this could make it into 8.2.1, or what the process
> would be toward getting it at least in the Rawhide/SOAS images, but it
> seems pretty low risk (assuming someone can tell me what I'm doing
> wrong w.r.t. ul-warning).
> yours,
> Bobby
> On Thu, Feb 19, 2009 at 3:03 AM, Mitch Bradley <wmb at laptop.org> wrote:
>> Cool!
>> Bobby Powers wrote:
>>> On Wed, Feb 11, 2009 at 2:01 AM, Mitch Bradley <wmb at laptop.org>  
>>> wrote:
>>>> I just measured the time taken by the boot animation by the simple
>>>> technique of renaming /usr/bin/rhgb-client so the initscripts  
>>>> can't find
>>>> it.
>>> how did you measure exactly? stopwatch? I'd like to recreate the
>>> tests.  It sounds like you did this on a freshly flashed system?
>> Yes on both counts.  Stopwatch on freshly-flashed os7.img .
>>>> With boot animation, OS build 7 (an older 8.2.1 candidate) takes 60
>>>> seconds from first dot (indicating OFW transfer to Linux) to Sugar
>>>> "prompt for your name".   Without it, 53 seconds.  I repeated the  
>>>> test
>>>> several times with consistent results.
>>>> Clearly, it should be possible to display that amount of  
>>>> information in
>>>> much less than 7 seconds.
>>>> The boot animation code is in the OLPC domain, not the upstream  
>>>> domain,
>>>> so replacing it should be relatively free of upstream politics.
>>>> So if anybody is interested in implementing a relatively simple
>>>> boot-time speedup, I offer this as low-hanging fruit.
>>>> I suggest 1 second (differential time between animation and no- 
>>>> animation
>>>> cases) as a reasonable target goal, assuming images of the  
>>>> complexity of
>>>> the current ones.  Arbitrary full-screen graphics might require  
>>>> more
>>>> time, but speeding up the baseline case is a good starting point.
>>>> Go wild.
>>> So I've taken a first cut at this, implemented with the following
>>> design considerations (mostly from a conversation with Mitch)
>>> - the Python client/server was reimplemented as several standalone C
>>> programs (boot-anim-start, boot-anim-client, and some cleanup in
>>> boot-anim-stop)
>>> - a client and server was used before because there is state
>>> information that needs to be saved: we need to keep track of where  
>>> in
>>> the animation we are.  We can keep track of this by using offscreen
>>> memory in the framebuffer (its 16MB in size, and only the first 2ish
>>> MB is used for the onscreen graphics (my terminology might be off
>>> here)).  For state we really only need to keep track of 2 integers,
>>> one for the current frame number and another to store the offset of
>>> the next diff to apply.
>>> - on startup we load an initial image into the framebuffer (the  
>>> first
>>> 1200*900*2 bytes, since we use 2 bytes per pixel for color
>>> information), and then load in a series of changes to the  
>>> framebuffer
>>> image (<300KB).  This takes the form of a series of diffs
>>> - for each update (a valid call to boot-anim-client) we apply the  
>>> next
>>> diff in the series to the onscreen image and update our state
>>> information
>>> - after applying the last diff we have (the end in the animation
>>> series), freeze the DCON (when I first attempted to freeze the DCON
>>> when z-boot-anim-stop was called it left the screen in an  
>>> inconsistent
>>> state, I believe because of X startup)
>>> - its designed to be as light as possible, using syscalls instead of
>>> libc functions as much as possible (the only thing we use libc for  
>>> is
>>> string comparison, which could be replaced with a local function).
>>> while its written like this, I haven't worked on cutting down the
>>> linking (I need some guidance for that)
>> To reduce the execution footprint, you could try linking it against
>> dietlibc, http://www.fefe.de/dietlibc/
>> I'm not sure just how much time that would save; maybe it wouldn't be
>> significant.  But it's worth a try.
>>> comments and suggestions welcome :)
>>> I'd appreciate any testing as well as any code review.  (the  
>>> shutdown
>>> image appears to be broken, FYI.  i haven't looked at that in depth,
>>> its probably a one line fix.)
>>> rpms (built with mock) are available at
>>> http://dev.laptop.org/~bobbyp/bootanim/
>>> and source is avail at
>>> http://dev.laptop.org/git?p=users/bobbyp/bootanim
>>> -Bobby
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel

More information about the Devel mailing list