On 08/16/2010 07:18 PM, Dianne Hackborn wrote: > Hi, very cool. Thanks - I was hoping someone would like it. :-)
> > For what it's worth, there are a series of event logs already in the platform > for key parts of the user space boot: > > I/boot_progress_start( 67): 31384 > I/boot_progress_preload_start( 67): 33117 > I/boot_progress_preload_end( 67): 37614 > I/boot_progress_system_run( 98): 38330 > I/boot_progress_pms_start( 98): 38853 > I/boot_progress_pms_system_scan_start( 98): 39432 > I/boot_progress_pms_data_scan_start( 98): 43593 > I/boot_progress_pms_scan_end( 98): 44363 > I/boot_progress_pms_ready( 98): 44668 > I/boot_progress_ams_ready( 98): 51363 > I/boot_progress_enable_screen( 98): 63810 > I/boot_progress_start( 1362): 921726 > I/boot_progress_preload_start( 1362): 923816 > I/boot_progress_preload_end( 1362): 925516 > I/boot_progress_system_run( 1365): 925798 > I/boot_progress_pms_start( 1365): 926173 > I/boot_progress_pms_system_scan_start( 1365): 926628 > I/boot_progress_pms_data_scan_start( 1365): 930639 > I/boot_progress_pms_scan_end( 1365): 931158 > I/boot_progress_pms_ready( 1365): 931426 > I/boot_progress_ams_ready( 1365): 938074 > I/boot_progress_enable_screen( 1365): 945150 I didn't see these at all. I'll dig into the code and try to find out why not. By the way, are those numbers milliseconds? > Zygote pre-loading is definitely an issue, though since it is necessary for > good performance later it is a challenge. The only thing I could think of is > on user builds to have the already initialized zygote as some kind of memory dump that can be read directly back in, instead of going through the re-loading of classes. Bleah. > > Package scanning is also a good target. This is basically an iteration > through all .apks to build the in-memory data structures for them, and you > can consider all of the work to be scanPackageLI for each of those .apks. Most of the optimization work so far has been on optimizing the loading and reading of .apks, since that also benefits many other things such as app launch time. That is probably getting pretty well optimized at this point, and it would be worth looking at things specifically to improve scanPackageLI. > > Note it isn't true that only AndroidManifest.xml is needed -- this is the > file that is read, but it can have references to other things in the .apk. > In particular, it will always need the resource table. Yes. I noticed that the resource table is also loaded. Also, it appears that certificates are checked. But I found the amount of I/O on the system to be proportional to the size of the package. For example, the Music package has a bunch of large wallpapers that are (apparently) paged into memory at boot time because of the way the archives are read. There should be a way to read the needed validation information with touching so much of the archive on the file system. > Also we shouldn't need to page in all of an .apk to open it as a zip... the > TOC is at the end of the zip, and that is all we should need to read to build > the in-memory data structures. If something in the code is causing the entire .apk to be touched to open it, that is a great candidate for optimization (and would be of benefit to all the other things that open .apks). > > I definitely wouldn't want to remove the signature checks... these are > important sanity checks for the package manager. In general I am worried > about doing optimizations that retain unchecked data about apps across boots, because it has the potential to include bugs that cause very bad behavior. We have already seen such things in production devices where manufacturers were apparently trying to optimize this code. So I'd focus solely on speeding up the work it currently does first, before eliminating work by retaining state across boots. The sanity checks, IMHO, would be better placed at the time of reading the (sub)file. As it is now, when the code opens a single file in an archive, every file in the archive has it's signature checked. Once things are in the page cache, this happens quickly, but it's still pretty wasteful. The archive index is rebuilt in user space, and the signature checks are repeated, if a package is accessed again later in the boot (which happens for a least Contacts.apk multiple times). > As far as package management being misdesigned because it isn't sitting on a > file system, this really misses the point. An application is an .apk, which > is a representation that can be transfered across devices. We deliberately do not want to have an install operation where we decompose that .apk on to a file system, and lose the original app, because there is very likely no way to get back to that .apk for transporting elsewhere. Note that this is not "building a persistent container and compression architecture in user space" -- it is just dealing with a representation of an application that is actually transportable. That's an interesting requirement, but I think you missed my point. The multiple abstraction layers in the code are causing things to be re-read multiple times. The kernel has the capability to consolidate handling of things like container boundaries, compression (or not) of individual sub-elements of a package, management of meta-data for the files, and to intelligently cache these operations, across processes, for performance. User space can't do this as well. Calling through multiple layers of code and relying on faults to load data implicitly instead of managing it explicitly with reads is inefficient, and less flexible in terms of I/O scheduling. On Sony devices, I'm not sure that re-export of a package would be a big requirement, but easy package validation and uninstall would be. In any case, I'll look at this some more with this requirement in mind, and see what turns up. By the way, I really appreciate your taking the time to look at this and give feedback and more information. Thanks a bunch. -- Tim ============================= Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Network Entertainment ============================= -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting
