08:31:19 <bero> #startmeeting
08:31:19 <linarobot> Meeting started Thu Nov  5 08:31:19 2015 UTC.  The chair is bero. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:31:19 <linarobot> Useful Commands: #action #agreed #help #info #idea #link #topic.
08:31:24 <bero> who is here?
08:31:30 * luther is here
08:31:36 <sunao> hi
08:32:08 <liuyq> bero, hi
08:32:17 <yspan> hi
08:32:36 <Qian_> hi
08:33:03 <bero> liuyq: do you want to go first?
08:33:22 <liuyq> What did you do?
08:33:22 <liuyq> Finished check on  Bug 795
08:33:22 <liuyq> Finished the check on utilization of �ifeq ($(TARGET_ARCH),arm64)� in the android source, changes upstreamed.
08:33:22 <liuyq> What are you going to do?
08:33:22 <liuyq> working on LMG-923: Check memory usage when building more code in Thumb-2 mode,
08:33:24 <liuyq> What problems do you have?
08:33:26 <liuyq> None
08:34:37 <liuyq> bero, just finished the task on bug795, working on the  LMG-923 about arm and thumb-2 mode now
08:35:13 <bero> good... yspan: next?
08:35:14 <liuyq> bero, I have a question about your status, but let's go ahead with others first
08:35:23 <bero> liuyq: sure
08:35:53 <yspan> hat did you do?
08:35:53 <yspan> I completed the dlopen method, but the amount of memory saving is only 4K :(. Other details are listed in https://projects.linaro.org/browse/LMG-415
08:35:53 <yspan> What are you going to do?
08:35:53 <yspan> LMG-941
08:35:53 <yspan> What problems do you have?
08:35:55 <yspan> none
08:36:16 <yspan> Saving only 4k is really disappointed :'(
08:36:21 <bero> Hmm... I would have hoped for more than 4K too
08:36:41 <bero> did you also try to locate any helper functions etc. that are used by the encoder only?
08:37:19 <bero> libpng relies on zlib for compression, maybe zlib is another one to split to make sure png reading doesn't pull in the compressor
08:37:20 <yspan> no. do you have any examples?
08:37:52 <yspan> hmm..
08:37:53 <bero> I don't, would have to check the code. Not too familiar with libpng's code
08:38:29 <bero> So let's continue LMG-415 a little with locating helper functions
08:38:47 <bero> some new assignees are supposed to start today, we can also push some of the work their way
08:39:15 <yspan> OK, as I know, official libpng already put encoding functions in pngwrite.c. If there is any function only used by encoder, then it should in pngwrite.c I guess. But I'll check
08:40:34 <yspan> that's all from me
08:41:36 <bero> ok good... luther: next?
08:41:48 * luther What did you do?
08:41:48 <luther> 1. c++ class std::set is designed from rb_tree template,
08:41:49 <luther> all set, rb_tree and allocator template code design are no longer more simpler,
08:41:49 <luther> no optimization space
08:41:49 * luther What are you going to do?
08:41:49 <luther> 1. look mutex.cc
08:41:51 * luther What problems do you have?
08:41:55 <luther> 1. none till now
08:43:39 <liuyq> yspan, bero, what's the theory size  supposed to be saved, 23K since dlclose is called?
08:44:04 <bero> thanks... Qian_: next?
08:44:27 <Qian_> What did you do?
08:44:29 <Qian_> I have asked some issues from bogden, and solved sed error yesterday.
08:44:29 <Qian_> Bogden has built SPEC with bero’s toolchain, and errors happens, I don’t verify it now.
08:44:29 <Qian_> Because android missed perl env, SPEC test failed
08:44:31 <Qian_> What are you going to do?
08:44:35 <Qian_> I think we should have a meeting with bogden for more discussion about SPEC
08:44:35 <Qian_> cross-compile perl to have a try.
08:44:37 <Qian_> What problems do you have?
08:44:41 <Qian_> it’s painful now, i don’t know we should go any further.
08:44:53 <Qian_> bero: I have met many problems
08:44:54 <bero> liuyq: depends on whether or not there's any more code we can move to the encoder... I was hoping at least around a third of the code would be used by the encoder only given encoding is a complicated process...
08:45:49 <bero> Qian_: yes, it seems to be more painful than it's worth, I've already talked to Tom about it. We might just drop it until some other things are done
08:46:30 <Qian_> yes, for me, i will try cross-compile perl
08:47:07 <Qian_> if it work, i will go on , or else we'd better stretch out
08:47:18 <bero> I'll try to get a final decision on whether or not we can drop it
08:47:31 <Qian_> ok
08:47:50 <bero> zhizhoutian_: next?
08:47:57 <Qian_> shall we have a meeting with bogden?
08:49:14 <bero> Qian_: yes, would be good to get a more detailed status to decide whether or not we should continue
08:49:30 <liuyq> Qian_, bero, don't know the details of SPEC, is it possible compile the target binary on host side, and just push them to device to run? running perl on host side without cross-compile perl for target side
08:49:34 <yspan> liuyq, in fact the LOC of pngwrite.c is not the biggest one in this case
08:50:14 <bero> liuyq: I don't know either, I was hoping that's the way it works, but apparently not...
08:50:41 <bero> liuyq: maybe bogden will know more
08:50:46 <Qian_> liuyq, yes,  that's is what i want to
08:51:22 <bero> Qian_: what liuyq is saying is essentially "don't cross-compile perl, run the perl bits on the host"
08:52:12 <Qian_> bero, i don't understand it
08:53:35 <Qian_> bero, liuyq, android doesn't have perl env now, so how it can run on andorid?
08:53:54 <bero> Qian_: what liuyq is thinking (and what I'm hoping too) is that probably the bits that are written in perl are just glue code to run the relevant parts -- so if it can be told to compile the other bits on the host and then just run the perl wrapper on the host (but make it run the tests written in other languages on the target) that would solve the problem
08:55:47 <Qian_> bero,but i think the almost framework is written by perl
08:56:15 <bero> yes - the question is if the framework can be made run on the host while executing the tests on another box
08:56:26 <bero> not sure if they thought of that sort of thing... maybe bogden will know
08:56:40 <bero> not sure if any of the actual tests are written in perl either
08:57:18 <Qian_> ok, let me try cross-compile perl for a try
08:57:56 <Qian_> ok, that's all from my side
08:57:59 <bero> yes, let's try that and catch up with bogden to see if there's an alternative then
08:58:04 <bero> sunao: next?
08:58:15 <sunao> What did you do?
08:58:17 <sunao> 1. test the memory usage of the dlmalloc memory allocator. sometimes, it use servral MB memory less than jemalloc. (some maybe not caused by memory allocator, but hard to identify).
08:58:18 <sunao> what are you going to do?
08:58:19 <sunao> 1. continue the investigate on memory allocator.
08:58:21 <sunao> 
08:58:23 <sunao> what problems do you have?
08:58:24 <sunao> 1.  None
08:59:01 <sunao> that's all from my side
08:59:25 <bero> good... so switching to dlmalloc for low memory builds might be a good option...
08:59:51 <sunao> if i can get the board next week , i will test it on the board on a multicore enviroment
09:00:00 <bero> guess it's my turn:
09:00:02 <bero> What did you do?
09:00:02 <bero> Patched build system to allow switching between size optimized vs. speed optimized in BoardConfig.mk
09:00:02 <bero> Tweaked 32-bit compiler flags some more
09:00:02 <bero> Task assignments for new Tinno/Spreadtrum assignees
09:00:02 <bero> Continued debugging Nexus 7 camera issue, but no success yet
09:00:02 <bero> What are you going to do?
09:00:02 <bero> Unbreak 64-bit builds that got broken by 32-bit optimizations
09:00:03 <bero> Add some size optimizations for TARGET_OPTIMIZE_FOR_SIZE=true builds
09:00:03 <bero> Check difference in memory consumption and speed between -O2/-Os/-Ofast builds
09:00:04 <bero> What problems do you have?
09:00:04 <bero> none
09:00:15 <bero> liuyq: you had a question there?
09:01:34 <liuyq> bero, yes, I see yspan, sunao and you all will check the memory consumption or memory size, are your all using the same method?
09:02:00 <bero> good question
09:02:36 <bero> I use dumpsys meminfo for the most part, and look at /proc for extra details
09:02:58 <bero> yspan: sunao: how do you check memory consumption/size?
09:03:22 <sunao> i use the dumpsys meminfo for the used and free meory, and the summary of native processor
09:04:01 <sunao> and some import process, such as zygote ,system_server
09:04:52 <bero> that seems to be essentially the same
09:05:02 <yspan> I use /proc/PID/smaps to see specific library usage
09:06:53 <bero> and that's part of what I mean by looking at /proc for extra details -- so I think for the most part we're on the same page
09:08:26 <liuyq> bero, yspan, OK, so we basically based on the dumpsys and /proc files for memory checking
09:08:48 <Qian_> any other tools exist now ?
09:09:03 <bero> liuyq: yes, looks like it - do you have any extra suggestions for stuff we should use additionally?
09:10:19 <sunao> the result of dumpsys memoinfo is too rough, we need to find out some other tools
09:10:20 <liuyq> bero, not yet, will share with the team if I get new methods.
09:11:09 <liuyq> bero, thanks, that's all from my side
09:11:47 <bero> sunao: that's why we've been looking at /proc/PID/smaps additionally -- but if you find something better, let us know...
09:12:11 <bero> It's always hard to tell what exactly is going on in a heavily multitasked system so overall stats are hard to get
09:12:30 <bero> I think we're through then... Have a great day everyone!
09:12:31 <sunao> yes, the memory usage is changing all  the time
09:12:36 <bero> #endmeeting