08:32:57 <xruxa> #startmeeting
08:32:57 <linarobot`> Meeting started Wed Dec  2 08:32:57 2015 UTC.  The chair is xruxa. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:32:57 <linarobot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
08:33:01 <xruxa> #chair bero
08:33:01 <linarobot`> Current chairs: bero xruxa
08:33:12 <Qian_> hi all
08:33:18 <xruxa> bero, you want to run it?
08:33:27 * liuyq is here
08:33:28 <bero> works either way
08:33:40 <bero> liuyq: do you want to go first?
08:34:10 <xruxa> is liuyq at Spreadrum offices today as well? (and zhizhoutian__ )
08:34:32 <zhizhoutian__> xruxa: I am in office
08:34:43 <liuyq> What did you do?
08:34:43 <liuyq> Investigated about the cts regression of member builds(seems not caused by the -ffast-math flag)
08:34:43 <liuyq> Checked the hikey jobs on LAVA.(still have cts-focused1, cts-focused2, vellamo3, andebenchpre failed for various probem, resubmitted and continue to see if there is obvious problem)
08:34:43 <liuyq> Helped on applying linaro patch for TShark device
08:34:43 <liuyq> What are you going to do?
08:34:47 <liuyq> Continue the investigation on cts bionic regression problem
08:34:49 <liuyq> Try to integrate the art into member build
08:34:51 <liuyq> What problems do you have?
08:34:53 <liuyq> None.
08:35:19 <bero> liuyq: good... did you get my mail? Would you mind if I reassigned LMG-347?
08:35:22 <liuyq> xruxa, no, today is at home. zhizhoutian__ helped to fix the problem, so I don't need to be there:) thanks, zhizhoutian__
08:35:31 <xruxa> liuyq, ack
08:35:42 <zhizhoutian__> liuyq: welcome
08:36:03 <liuyq> bero, yes, please reassign LMG-347
08:36:07 <bero> ok, thanks
08:36:18 <bero> Qian_: do you want to go next?
08:36:22 <Qian_> What did you do?
08:36:24 <Qian_> Investigate LMG-914, writing a script for analysis
08:36:24 <Qian_> What are you going to do?
08:36:24 <Qian_> Continue Investigate LMG-914
08:36:26 <Qian_> Change workplace tomorrow
08:36:28 <Qian_> What problems do you have?
08:36:30 <Qian_> none
08:36:40 <xruxa> liuyq, bero - it looks like the latest HiKey M-LCR is faster than the one before - anyone with ideas why? (like member LCR patches, or such)?
08:38:13 <bero> xruxa: there's a couple of Bionic patches forward-ported from the last L based M-LCR and there's some of the CPU optimization stuff I added to both the ram patchset and the M-LCR patchset. Those 2 combined probably make it faster. How much of a difference do you see?
08:38:44 <bero> Qian_: good, "Change workplace" means "go to another office" and not "change jobs", right?
08:39:16 <Qian_> bero: Yes, we will move to a new building
08:39:33 <bero> good, would be really bad to see you leaving again so soon ;)
08:39:44 <bero> yspan: do you want to go next?
08:39:55 <xruxa> bero, some benchmarks are now 2 times faster, some did not change. I guess we need to start benchmarking also the reference LCR for HiKey to have something to compare against.
08:40:24 <yspan> What did you do?
08:40:24 <yspan> liuyq suggests device/linaro/juno/device.mk is OK for PRODUCT_PACKAGES += libpng-enc.
08:40:24 <yspan> What are you going to do?
08:40:24 <yspan> I will send patch for review after basic test.
08:40:24 <yspan> What problems do you have?
08:40:27 <yspan> no
08:40:44 <bero> xruxa: It would surprise me if they had that much of an effect, but maybe it's just very specific benchmarks testing exactly the functionality
08:40:54 <xruxa> bero, ack
08:43:08 <bero> yspan: thanks... I don't think device/linaro/juno/device.mk is the best place (because that would mean we have to add it to every device we want to support)... yspan/liuyq: What do you think about adding it to something like build/target/product/core.mk or a similar place?
08:44:10 <yspan> bero, I have the same concern :p
08:46:17 <bero> zhizhoutian__: do you want to go next?
08:46:41 <zhizhoutian__> What did you do?
08:46:41 <zhizhoutian__> - LMG-984 Optimize zramfs
08:46:41 <zhizhoutian__> * I found latest kernel-stable code use lz4 or lzo compress method. Is this "lz4" better than LZMA2 or lzo?
08:46:41 <zhizhoutian__> * Latest kernel-stable(4.4) use multi-stream to compress, but current code(3.10) did not.
08:46:41 <zhizhoutian__> What are you going to do?
08:46:41 <zhizhoutian__> What problems do you have?
08:46:41 <zhizhoutian__> 1. Does lz4 better than lzo? How to measure it?
08:46:42 <zhizhoutian__> 2. How to implement multi-stream? How to know it is better than before?
08:47:15 <bero> So it's hard to tell which of the compression algorithms are best -- that's why we have to try them all...
08:47:32 <bero> They differ mostly in how good they compress vs. how fast they run
08:47:43 <zhizhoutian__> yes
08:48:01 <bero> LZ4 is super fast but not that good at compressing
08:48:15 <zhizhoutian__> And i do not know how to measure and compare them
08:48:16 <bero> lzo is slightly better at compressing and a bit slower
08:48:22 <zhizhoutian__> ok
08:48:33 <bero> LZMA2 is on the other end of the scale, it compresses really well but is really slow
08:48:56 <bero> so which works best really depends on how much CPU power we're ready to waste in order to make some room
08:49:01 <zhizhoutian__> how you get those result?
08:49:16 <zhizhoutian__> yes
08:49:43 <sunao> Can any of these algorithms be accelerated by hardware?
08:49:45 <bero> That's just from knowing what the compression systems were designed for, I didn't run any tests in the context of zramfs so far
08:49:45 <zhizhoutian__> bero: i want to know how you compare them and get those result?
08:50:10 <zhizhoutian__> i see.
08:50:39 <bero> Inside zramfs, I don't know... Outside of zramfs, there's various tools that use the same algorithms so you can check...
08:50:43 <bero> lzo is here: http://www.oberhumer.com/opensource/lzo/
08:51:01 <bero> lz4 is here: https://github.com/Cyan4973/lz4
08:51:11 <zhizhoutian__> the issue is: lz4 is used in latest kernel, i can not test it on current hardware
08:51:20 <bero> lzma2 is used by xz (which is present on pretty much any modern linux system)
08:51:20 <zhizhoutian__> bero: ok, thanks
08:52:12 <bero> I think we can go with lzo for now, it probably is the most reasonable compromise between CPU speed and compression efficiency given it's somewhere in the middle (somewhat closer to favoring CPU speed)
08:52:28 <zhizhoutian__> yes
08:52:29 <bero> sunao: That's a good question - I'd hope they all can be accelerated to some extent
08:53:48 <zhizhoutian__> so I should target on multi-stream, not lz4 or lzo
08:53:59 <zhizhoutian__> focus*
08:54:26 <liuyq> bero, yspan, build/target/product/core.mk would be a better place, but I think it's better to find why libpng.so is integrated and make libpng-enc.so the same place.
08:54:29 <bero> https://en.wikipedia.org/wiki/Brotli <-- this may be interesting as well, but I don't think there's an implementation of it in the kernel yet, so that would mean a lot of work
08:54:56 <bero> zhizhoutian__: yes, I'd agree. multi-stream seems to be quite a step forward
08:54:56 <zhizhoutian__> there are two way i can try: 1. port lz4 to current hardware 2. run latest kernel on virtual machine(qemu)
08:55:06 <zhizhoutian__> ok
08:55:56 <bero> liuyq: I think libpng is pulled in automatically because other stuff depends on it - can't pull in libpng-enc the same way unless we start linking stuff to it (which we want to avoid)... But I might be wrong
08:56:39 <bero> zhizhoutian__: I think let's see if it's worth porting before investing time into it... We may just end up deciding lzo is the better choice anyway
08:57:28 <zhizhoutian__> bero: ok
08:58:33 <bero> eric____: I think you've been blocked by the webp task having already been done upstream - I've assigned you a new task: https://projects.linaro.org/browse/LMG-347
08:59:02 <eric____> good, :)
08:59:10 <bero> eric____: Essentially, try to rebuild the browser package linking to system libraries instead of bundling its own copies of libjpeg, libpng, zlib, ...
08:59:20 <bero> eric____: is that ok?
08:59:27 <eric____> fine
08:59:37 <bero> good
08:59:45 <bero> wuhai: do you want to go next?
08:59:47 <eric____> and another question
08:59:54 <wuhai> OK
09:00:08 <wuhai> What did you do?
09:00:08 <wuhai> 1.Apply the marshmallow-ram-patchset and marshmallow-gcc5-patchset  patch to T-Shark baseline   .
09:00:08 <wuhai> 2.Compile T-Shark image but with error when we set "export TARGET_GCC_VERSION_EXP=5.2-linaro".
09:00:08 <wuhai> 3.Found error in T-shark kernel uboot and chipram,so we only change toolchain to 5.2-linaro for systemimage,and kernel uboot chipram use the original toolchain as before. now being compiled, it seems to be normal.
09:00:08 <wuhai> what are you going to do?
09:00:08 <wuhai> Verify the linaro patch effect on T-Shark baseline.
09:00:08 <wuhai> what problems do you have?
09:00:09 <wuhai> None until right now
09:00:24 <bero> eric____: sure, go ahead
09:00:38 <eric____> you told me that you would ask google engineer about static analyzer, any news?
09:00:47 <yspan> liuyq, bero, core.mk contains APPs, and base.mk contains libraries. Thus, I prefer base.mk
09:01:16 <bero> wuhai: thanks, btw, you also want to export TARGET_OPTIMIZE_FOR_SIZE=true, a number of the ram related patches are activated only if that is set.
09:01:34 <bero> eric____: didn't get a reply yet (I presume that means either he's on vacation or he hasn't tried yet either)
09:01:49 <wuhai> yes ,i set export TARGET_OPTIMIZE_FOR_SIZE=true  too
09:01:53 <eric____> bero: got it
09:01:58 <bero> yspan: yes, that probably is the better place.
09:02:11 <bero> wangjian: do you want to go next?
09:02:34 <wangjian> What did you do?
09:02:35 <wangjian> Apply Bero patches set to T-Shark and build with Wuhai,fix the build error cause by gcc changed from 4.9 to 5.2.
09:02:35 <wangjian> What are you going to do?
09:02:35 <wangjian> When build completed ,download to T-Shark 512M/1G devices to compare the memory usage with no Bero's patch.
09:02:35 <wangjian> What problems do you have?
09:02:35 <wangjian> Spreadtrum has done a lot of optimization for the launcher and does not merger into T-SHARK code now.
09:02:35 <wangjian> I found that launcher optimized work is too details to modify code, which requires a lot of time to debug, and for a specific platform, such as T-SHARK, the code differences very large to AOSP, so I think LMG-954 is useless.
09:02:36 <wangjian> I want to get another tast after verify Bero's patches set on T-Shark.
09:03:52 <bero> wangjian: yes, we probably need to check with Spreadtrum if there's anything in their launcher modifications we can pull into the other builds as well, looks like they've already done some work there
09:04:20 <wangjian> bero: yes
09:04:36 <bero> sunao: do you want to go next?
09:04:44 <sunao> What did you do?
09:04:46 <sunao> 1. change the mmap threshold paramete from 256KB to 128KB, but has no improvement, still analysing.
09:04:47 <sunao> 2. get the code of ptmalloc, try to analyse
09:04:49 <sunao> what are you going to do?
09:04:50 <sunao> 1. investigate the ptmalloc, port it to Android.
09:04:52 <sunao> what problems do you have?.
09:04:53 <sunao> 1.  None.
09:05:31 <bero> sunao: thanks
09:05:37 <bero> luther: are you back from company work?
09:06:37 <luther> bero: sorry, no
09:07:35 <sunao> yspan, have you ever tried to add the libpng-enc to libpng's shared library list, this will make a fake dependency. maybe it works. not quite sure
09:07:52 <bero> luther: that's ok
09:08:23 <bero> ok, I think among the people who are here that leaves me
09:08:33 <bero> What did you do?
09:08:33 <bero> Cleaned up a few more patches to go into the ram patchset
09:08:33 <bero> Some progress with external clang
09:08:33 <bero> Read up on TCWG’s plans with LLVM
09:08:33 <bero> Android Consolidation meeting
09:08:33 <bero> What are you going to do?
09:08:33 <bero> Check out LTO support in AOSP master’s clang
09:08:34 <bero> Continue attempts to build with external clang
09:08:34 <bero> What problems do you have?
09:08:35 <bero> none
09:08:41 <Qian_> wuhai: where can i find the the patches?
09:08:43 <bero> did I forget anyone or does anyone have more topics?
09:09:01 <Qian_> wuhai: both ram and gcc
09:09:31 <yspan> sunao, do you mean set libpng's LOCAL_SHARED_LIBRARIES := libpng-enc ...
09:10:27 <sunao> yes,
09:10:38 <wuhai> Qian_: you can download android-patchsets ,and you can see them
09:10:46 <sunao> I have not test it, maybe it can work
09:10:58 <zhizhoutian__> bero: linux4.4 are using multi-stream compression but linux3.10 not. maybe i have to port them. do you have any advice or tools?
09:11:21 <Qian_> wuhai: Thanks
09:11:24 <bero> I think that would actually link libpng to libpng-enc, bringing back the memory use we eliminated by removing those functions in the first place...
09:11:29 <bero> but it would drag it in...
09:11:30 <yspan> sunao, because libpng-enc link to libpng, If I set libpng link to libpng-enc that would be cyclic
09:12:00 <sunao> yspan, oh that's possible
09:12:19 <bero> zhizhoutian__: not really... I usually backport stuff by copying in the newer code and seeing if anything breaks
09:12:31 <bero> I don't think there's any special tools
09:12:42 <bero> sumits: would know better though
09:12:44 <zhizhoutian__> bero: ok;)
09:14:01 <zhizhoutian__> bero: right... I should reply sumits's advice. i have finished investigation.
09:22:04 <bero> #endmeeting