08:33:14 <bero> #startmeeting
08:33:14 <linarobot`> Meeting started Thu Dec  3 08:33:14 2015 UTC.  The chair is bero. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:33:14 <linarobot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
08:33:49 <bero> So small update: It currently looks like the sprint will happen in the 2nd week of January, 4th to 8th
08:33:58 <bero> This is not final though, can still change around
08:34:18 * liuyq is here
08:36:08 <bero> So, on to the daily reports...
08:36:21 <bero> yspan: Do you want to go first?
08:36:30 <yspan> ah, ok
08:36:38 <xruxa> #info  It currently looks like the sprint will happen in the 2nd week of January, 4th to 8th
08:36:54 <yspan> What did you do?
08:36:54 <yspan> https://dev-private-review.linaro.org/#/c/449/
08:36:54 <yspan> What are you going to do?
08:36:54 <yspan> cross finger :p
08:36:54 <yspan> What problems do you have?
08:36:56 <yspan> none
08:37:14 <bero> yspan: thanks, will try adding the patch again today
08:37:16 <xruxa> lol
08:37:21 <bero> liuyq: do you want to go next?
08:37:39 <liuyq> What did you do?
08:37:39 <liuyq> Tested compilation and bootup of art optimization integration with HiKey. Wait for ART team review to merge that change.
08:37:39 <liuyq> Investigated about the CTS bionic regression on member builds(probably related to -mfpu=neon option, building is in progress)
08:37:39 <liuyq> 
08:37:39 <liuyq> What are you going to do?
08:37:41 <liuyq> Continue to check the CTS bionic regression on member builds
08:37:43 <liuyq> Merge the art integration change
08:37:45 <liuyq> Check the andebench problem on HiKey
08:37:47 <liuyq> What problems do you have?
08:37:49 <liuyq> Hikey build on hackbox can not boot the grub menu.
08:38:17 <bero> Anything we can do to help fix up Hikey?
08:38:25 <sunao> test
08:38:38 <bero> sunao: got the message
08:39:00 <liuyq> bero, I tried the -ffast-math option, it does not cause the cts bionic regression on member build. I am checking the -mfpu=neon flag now
08:39:42 <bero> interesting - I'd have thought -ffast-math would be to blame given it's designed to reduce accuracy for speed and size
08:39:51 <liuyq> bero, for the HiKey problem, the images built on my local side works, but my the build time on my local side is longer, so I want to build it on hackbox
08:40:04 <bero> but guess it's not the only one
08:40:14 <bero> hmm, weird. Maybe hackbox is missing some tools
08:40:29 <bero> or running an ancient version of some tools
08:40:46 <liuyq> bero, I checked the grub.cfg and binaries, seems ok
08:41:13 <bero> hmm, any idea what the difference might be?
08:41:24 <liuyq> bero, no idea yet
08:42:13 <bero> guess we'll have to figure it out over the next couple of days
08:42:21 <bero> zhizhoutian__: do you want to go next?
08:42:43 <zhizhoutian__> What did you do?
08:42:43 <zhizhoutian__> - trace linux-stable(4.4)’s zram module(especially multi-stream) step by step with VM
08:44:32 <zhizhoutian__> bero: that is all... kernel code is not easy to read for me.
08:45:12 <zhizhoutian__> bero: so i need time to see how does it work in latest zram module.
08:45:19 <bero> that's ok, zramfs isn't an easy task
08:45:31 <bero> take the time you need...
08:45:39 <zhizhoutian__> thanks;)
08:46:02 <bero> eric____: do you want to go next?
08:47:05 <eric____> yes
08:47:25 <eric____> What did you do?
08:47:36 <eric____> Investigate the libraries called by browser;
08:47:47 <eric____> What are you going to do?
08:47:57 <eric____> Investigate the libraries called by browser, and rebuild it linking to system libraries instead of bundling its own copies of libjpeg, libpng, zlib, ...
08:48:14 <eric____> What problems do you have?
08:48:21 <eric____> In LMG-347, it is webview, so does this “browser” means the same thing with webview?
08:49:02 <eric____> I'm a little confused, that in Jira, it's webview, but you told me to rebuild browser
08:49:17 <eric____> what do you think about it? bero
08:49:53 <eric____> system libraries means static lib or dynamic? or both?
08:50:04 <bero> eric____: Essentially the browser is just a thin layer that talks to the webview, so it comes down to the same thing. webview is the one to really look at
08:50:21 <bero> essentially we need to replace external/chromium-webview/prebuilt/arm/webview.apk with a version that uses system libraries
08:51:02 <eric____> OK, got it
08:51:46 <eric____> thanks
08:53:45 <bero> thanks
08:53:50 <bero> sunao: do you want to go next?
08:54:00 <sunao> What did you do?
08:54:02 <sunao> 1。 try to analyse the code of ptmalloc. very little progress.
08:54:03 <sunao> what are you going to do?
08:54:05 <sunao> 1. investigate the ptmalloc, port it to Android.
08:54:07 <sunao> what problems do you have?.
08:54:08 <sunao> 1.  None.
08:54:19 <bero> thanks
08:54:34 <bero> xavierhsu: do you want to go next?
08:54:39 <xavierhsu> ok
08:54:52 <xavierhsu> What did you do?The build-in app (Gallery) will call libjpeg-enc.so then occur error(error in the function "jpeg_write_scanlines") but other jpeg related android apps will not call libjpeg-enc.so, so they can be normally be used.
08:55:01 <sunao> bero, build ptmalloc to a static lib and link it to libc or add the code directly to libc , which one do you think is better?
08:55:03 <xavierhsu> What are you going to do?I need to check the function "jpeg_write_scanlines".
08:55:13 <xavierhsu> What problems do you have?Debug now.
08:55:32 <xavierhsu> Bero, Could you give me some suggestion?
08:56:28 <bero> sunao: either would work, guess it's best to add it the same way dlmalloc and jemalloc are added, gives it a higher chance of being accepted upstream if it gives better results.
08:57:02 <sunao> jemalloc is a static lib and dlmallc add code directly
08:57:42 <bero> xavierhsu: Not exactly sure what's going on there, but it would look to me like either jpeg_write_scanlines isn't being loaded correctly (it should just work when pulled in through dlopen after all) or possibly libjpeg does something "evil" like keeping stuff in global variables that don't survive across dlopen/dlclose calls...
08:58:04 <bero> sunao: let's go for the static lib approach then, probably makes it easier to swap it out
08:58:26 <sunao> bero, thank you, anyway, i need to get it work first...
08:58:45 <bero> right, and we need to see if it actually does better
08:59:02 <sunao> thansk bero, that's all from myside
08:59:12 <bero> sunao: thanks
08:59:16 <bero> wuhai: do you want to go next?
08:59:30 <wuhai> What did you do?
08:59:30 <wuhai> 1.Compile success for T-Shark baseline after apply the linaro patch.
08:59:30 <wuhai> 2.Download T-shark image to device but with error,because fastboot can't found devices on fastboot mode.Fixed this bug.
08:59:30 <wuhai> 3.Verify the linaro patch effect on T-Shark baseline.
08:59:30 <wuhai> what are you going to do?
08:59:30 <wuhai> Verify the linaro patch effect on T-Shark baseline.
08:59:30 <wuhai> what problems do you have?
08:59:31 <wuhai> I still need to continue to work in LMG-963 ? because the android-M has done a lot in this optimized,and it has been updated JIAR for my story.
08:59:31 <wuhai> I think I can do someting that linaro the patch port to t-shark baseline and verify patch effect,Learning the role of patch
09:01:53 <bero> I'd guess for LMG-963 there's still some room for optimization, but there may be easier targets if it's already optimized that much, so let's de-prioritize it and get back to it if we run out of other ideas
09:02:13 <bero> We'll need people to make sure patches apply and are effective on top of T-Shark...
09:02:24 <bero> I can't help much with that because I have neither the hardware nor the BSP
09:02:35 <bero> but of course if you run into any errors with it let me know
09:03:50 <bero> yuxing: do you want to go next?
09:03:58 <wuhai> yes ,but i need to understanding  the role  of patch
09:04:04 <yuxing> ok
09:04:17 <yuxing> What did you do?
09:04:37 <yuxing> 1、 finished  enable ksm on mobile (CONFIG_KSM and write 1 to /sys/kernel/mm/ksm/run in init.rc file )
09:04:47 <bero> wuhai: look at the comments in the patchset file and the commit logs in the gerrit entries the patches are pulled from
09:04:59 <yuxing> 2、 I found user program  used the madvise system call to set the ksm mergeable area  ,  At current android.60 source code,  in the malloc interface , through call  madvise() set ksm mergeable area at the anonymous memory
09:05:15 <yuxing> What are you going to do?
09:05:17 <bero> wuhai: that should show what they do for all of them
09:05:22 <yuxing> 1、Look at the specific process is how to set up the KSM can merge area , such as servicemanager 、surfaceflinger
09:05:37 <yuxing> what problems do you have?
09:05:47 <yuxing> 1、current ksm only support scan anonymous memory , can we  add some other type memory ?
09:05:49 <wuhai> ok ,I got it
09:05:55 <yuxing> 2、 how many memory type can be added the  ksm mergeable ?
09:06:04 <yuxing> 3、how to test the affect when we add the new  mergeable area
09:07:27 <yspan> yuxing, just curious: did you see how many pages are merged?
09:07:38 <bero> yuxing: good questions, maybe sumits can answer them best
09:08:01 <bero> but I doubt it can work effectively for anything but anonymous memory
09:09:27 <yuxing> yspan: no I mean can we add other type memory but  anonymous memory
09:09:58 <bero> ok, I think among the people who are there that leaves just me
09:10:00 <bero> What did you do?
09:10:00 <bero> Fixed a few more issues with external clang builds
09:10:00 <bero> Cleaned up a few more patches to prepare them for going into the patchset
09:10:00 <bero> Read and commented on the 2016 OKR
09:10:00 <bero> What are you going to do?
09:10:00 <bero> Merge more patches into the patchset
09:10:00 <bero> Continue work on building with external clang
09:10:01 <bero> Check out LTO support in clang on AOSP master
09:10:01 <bero> What problems do you have?
09:10:02 <bero> none
09:10:08 <bero> did I forget anyone?
09:10:28 <bero> or do we have any extra topics?
09:11:20 <yuxing> sumits : are you here?
09:11:46 <bero> #endmeeting