Opportunity for speedup

[Bobby Powers]

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.

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
>>
>
>