[PROPOSAL] Android boot time improvements


Bird, Tim <Tim.Bird@...>
 

On Thursday, October 03, 2013 2:28 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
here I get board with a full system + QT UI in 300ms running from cold start.
Wow! That's really impressing. Can you provide any details? Is that from power on
to Qt driving the gui with an image up? Are you doing XIP? I haven't seen times
under 500 ms. unless people are doing some form of XIP, because binaries
are getting so big these days that just the load/link times are getting bad.
Did you statically link or pre-link?

Thanks - any details on this would be great. I'm trying to find examples of
quick boot, to use for the "state of the art" for my status presentation
at ELCE.

You must specify what means boot time because boot time can be up to the
prompt or up to specific application feature that is customer specific not
general purpose
Agreed. It's valuable to see new boot-time enhancement techniques. But
we should be specific about what the limits are, relative to other techniques.
One appeal of the checkpoint technique is that it appears to be general-purpose.
I'm not sure what technique is being proposed in Artemi's project.

As an aside, I'm not sure why checkpoint isn't referred to as hibernation, but I
haven't looked into the details.
-- Tim


Bird, Tim <Tim.Bird@...>
 

On Wednesday, October 02, 2013 11:27 PM, Artemi Ivanov wrote:

; Summary: Android boot time improvements
; Proposer: Artemi Ivanov

== Description ==
Android boot time could be dramatically improved by leveraging
checkpoints/snapshots approaches (might be sufficient for variety of
products/use cases), on the other side it would be great to study deeper
if Android cold boot speed could be improved, at least for
automotive/IVI scenarios (get display/video/audio enabled early)

== Related work ==
* 0xlab survey - Shorten Device Boot Time for Automotive IVI and
Navigation Systems; Implement Checkpointing for Android; Android Boot
Time Optimization
* CELF Boot time page - http://elinux.org/Boot_Time

== Scope ==
* Leverage most powerful hw platforms (multicore Cortex-A15 SOCs, fast
storage, etc.)
* Get max of what could be optimized at bootcode/kernel level (this
could be done in a week or so - using boottime cook books)
* Try to get Android booting to UI/video/audio in a couple of seconds
range (i.e. custom/automotive-focused use-case)...
* Compare results with snapshots/checkpoints implementation
Thanks for this proposal. Just to clarify - are you describing getting the
Android framework up quickly, or doing a side-load of AV functionality
in order to get to a specific feature (video playback) quickly?

If the former, I have walked my own trail of tears on this path. It's a difficult
problem, due to the architecture of the system. If you have some new insights
here I'm very interested (at least personally). If you're talking about
side-loading, then how do you envision handing the switchover of resources
to java-based software, once the system is up?

Thanks,
-- Tim

BTW: elinux page is at: http://elinux.org/Android_boot_time_improvements


Jean-Christophe PLAGNIOL-VILLARD
 

On 10:11 Thu 03 Oct , Geert Uytterhoeven wrote:
On Thu, Oct 3, 2013 at 9:31 AM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@...> wrote:
Android boot time could be dramatically improved by leveraging
checkpoints/snapshots approaches (might be sufficient for variety of
products/use cases), on the other side it would be great to study
deeper if Android cold boot speed could be improved, at least for
automotive/IVI scenarios (get display/video/audio enabled early)
what is the booting target?

I've done in the past on non optimised android < 30s from cold start to UI
on arm926ejs with base Android < 30s
on more complex and full feature Android on Cortex-A9 (5 MiB kernel) < 30s
with optimised bootloader (barebox)
Hmm, 30 seconds can be a long time ;-)

For user interaction, the typical guideline is: upon any user activity,
the system should respond within 500 ms, either by performing the
operation, or by giving an indication about it's progress.

if I e.g. fetch my camera and turn it on, I want to take a picture within
500 ms.
That is exactly the issue here what means boot time.

here I get board with a full system + QT UI in 300ms running from cold start.

You must specify what means boot time because boot time can be up to the
prompt or up to specific application feature that is customer specific not
general purpose

Best Regards,
J.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Geert Uytterhoeven
 

On Thu, Oct 3, 2013 at 9:31 AM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@...> wrote:
Android boot time could be dramatically improved by leveraging
checkpoints/snapshots approaches (might be sufficient for variety of
products/use cases), on the other side it would be great to study
deeper if Android cold boot speed could be improved, at least for
automotive/IVI scenarios (get display/video/audio enabled early)
what is the booting target?

I've done in the past on non optimised android < 30s from cold start to UI
on arm926ejs with base Android < 30s
on more complex and full feature Android on Cortex-A9 (5 MiB kernel) < 30s
with optimised bootloader (barebox)
Hmm, 30 seconds can be a long time ;-)

For user interaction, the typical guideline is: upon any user activity,
the system should respond within 500 ms, either by performing the
operation, or by giving an indication about it's progress.

if I e.g. fetch my camera and turn it on, I want to take a picture within
500 ms.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Jean-Christophe PLAGNIOL-VILLARD
 

On 10:27 Thu 03 Oct , Artemi Ivanov wrote:
; Summary: Android boot time improvements

; Proposer: Artemi Ivanov

== Description ==
Android boot time could be dramatically improved by leveraging
checkpoints/snapshots approaches (might be sufficient for variety of
products/use cases), on the other side it would be great to study
deeper if Android cold boot speed could be improved, at least for
automotive/IVI scenarios (get display/video/audio enabled early)
what is the booting target?

I've done in the past on non optimised android < 30s from cold start to UI
on arm926ejs with base Android < 30s
on more complex and full feature Android on Cortex-A9 (5 MiB kernel) < 30s

with optimised bootloader (barebox)


== Related work ==
* 0xlab survey - Shorten Device Boot Time for Automotive IVI and
Navigation Systems; Implement Checkpointing for Android; Android
Boot Time Optimization
* CELF Boot time page - http://elinux.org/Boot_Time

== Scope ==
* Leverage most powerful hw platforms (multicore Cortex-A15 SOCs, fast
storage, etc.)
more powerfull hw does not mean shorter boot time

to be able to comparare anything we need have similar hw feature as more
driver you have to load means more time to boot. I also could have hw design
issue on dev board that slow down the boot

* Get max of what could be optimized at bootcode/kernel level (this
could be done in a week or so - using boottime cook books)
* Try to get Android booting to UI/video/audio in a couple of seconds
range (i.e. custom/automotive-focused use-case)...
* Compare results with snapshots/checkpoints implementation

Efforts: 6-8 weeks

== Contractor Candidates ==


== Comments ==


[[Category:Project proposals 2013]]
_______________________________________________
Celinux-dev mailing list
Celinux-dev@...
https://lists.celinuxforum.org/mailman/listinfo/celinux-dev


artemi.ivanov@cogentembedded.com
 

; Summary: Android boot time improvements

; Proposer: Artemi Ivanov

== Description ==
Android boot time could be dramatically improved by leveraging checkpoints/snapshots approaches (might be sufficient for variety of products/use cases), on the other side it would be great to study deeper if Android cold boot speed could be improved, at least for automotive/IVI scenarios (get display/video/audio enabled early)

== Related work ==
* 0xlab survey - Shorten Device Boot Time for Automotive IVI and Navigation Systems; Implement Checkpointing for Android; Android Boot Time Optimization
* CELF Boot time page - http://elinux.org/Boot_Time

== Scope ==
* Leverage most powerful hw platforms (multicore Cortex-A15 SOCs, fast
storage, etc.)
* Get max of what could be optimized at bootcode/kernel level (this
could be done in a week or so - using boottime cook books)
* Try to get Android booting to UI/video/audio in a couple of seconds
range (i.e. custom/automotive-focused use-case)...
* Compare results with snapshots/checkpoints implementation

Efforts: 6-8 weeks

== Contractor Candidates ==


== Comments ==


[[Category:Project proposals 2013]]