**** BEGIN LOGGING AT Mon Sep 18 03:00:01 2017 **** BEGIN LOGGING AT Mon Sep 18 08:08:04 2017 Sep 18 13:31:34 I see a lot of HOMEPAGE commits, any background I missed? Sep 18 14:45:04 Crofton: WR is filling them in, no doubt they have a reason Sep 18 14:45:24 the recent patches were from Fujitsu Sep 18 14:45:41 WR does them as part of the regular recipe maintenance.. but we don't usually add new ones to recipes we don't maintain. Sep 18 14:45:50 The layerindex does pay attention to things like homepage.. Sep 18 14:46:01 So if someone is using it to lookup recipes, it is useful Sep 18 14:46:56 http://layers.openembedded.org/layerindex/recipe/81/ Sep 18 14:46:59 i.e. homepage is listed Sep 18 15:20:58 Thanks guys! Sep 18 15:31:16 fray, do you need those HOMEPAGE changes back ported? Sep 18 15:31:42 don't look at me.. I didn't make them Sep 18 15:31:59 armpit: if you can be bothered i guess :) Sep 18 15:32:03 We just keep them updated in recipes we support.. since updated recipes don't usually get backports, not a problem Sep 18 15:32:16 As I said, Fujitsu is the one that has been sending updates recently Sep 18 15:32:33 why did i think it was WR? :) Sep 18 15:33:03 huangqy.fnst@cn.fujitsu.com Sep 18 15:33:32 (don't get me wrong, i think it's a good addition to the system and helps the layerindex and such... but it's very much cosmetic) Sep 18 15:34:51 ah, mistaken the sender was from WR without looking at the email adder Sep 18 15:35:51 rburton: if you like WR could reformat all recipes to be more consistent and add decorator comments and a style checker! :-P Sep 18 15:36:10 haha no thanks Sep 18 15:36:11 Randy, you should get right on that.. ;) Sep 18 15:36:15 heh Sep 18 21:36:02 * armpit wow, got prelink to coredump Sep 18 21:38:24 oh thats not hard :) Sep 18 21:44:07 during build? Sep 18 21:45:44 * armpit cleans up build Sep 18 21:57:27 do we still need prelink in 2017 Sep 18 21:59:23 fray insists that it is still useful :) Sep 18 21:59:31 * rburton asked that when it last broke Sep 18 22:00:34 really, well may be Sep 18 22:01:07 khem, I have not evaluated performance on master. Last time I did was 2.2. In 2.2 it made a hugh impact on ARM systems for boot performance. Sep 18 22:01:22 which arm Sep 18 22:01:23 it really was the difference between meeting memory and boot performance requirements or not Sep 18 22:01:40 32-bit Sep 18 22:01:47 64-bit is only partially impleented Sep 18 22:01:47 we have 64bit AMBA interconnect now a day s Sep 18 22:02:03 if someone can help me finish implementing the 64-bit support, I could instrument that.. Sep 18 22:02:39 all instrumentation was done using meminfo stuff... the performance pieces were using the internal performance counters within glibc (as well as using items like 'time') Sep 18 22:03:47 I'm curious what load time is for musl and if it would help there as well -- but someone would have to adjust the dynamic loader to actually use the prelinking hints Sep 18 22:04:43 (and yes, we still have a -lot- of customers doing 32-bit arm designs.... 32-bit intel designs are pretty much gone... 64-bit exist, but due to the slow bios boot performance isn't usually an issue.. and 'memory is cheap' on x86) Sep 18 22:05:12 (there are some custom firmware for x86 that can make it so boot performance actually matters.. but they are fairly rare still) Sep 18 22:14:55 how much speedup does prelinker result in on avg Sep 18 22:15:41 can it work with PIE executables ? Sep 18 22:17:02 speedup is all on loading.. in the small library case (command line stuff).. it's pretty good... but if you move to C++ applications, it's a -huge- improvement.. Sep 18 22:17:07 (Sorry I don't have figures handy) Sep 18 22:17:37 I BELIEVE PIE works, but the downside is it effectively determines load address/run address prior to run-time.. which avoids ASLR and such Sep 18 22:18:40 so there are two pieces.. load time -- the dynamic loader can just aovid all of the relocations.. the second are weak (runtime) relocations can be avoided in many cases.. (IFUNCS are not for instance) Sep 18 22:19:43 but don't expect a big runtime performance difference (in most cases it probably isn't noticable).. but load time is a big deal.. so if you are running a lot of programs, you also get two secondary benefits.. 1) less memory used for loading so more can be loaded from cache... (that itself can be a huge memory boost due to COW caching) Sep 18 22:20:09 2) less power usage (for loading) because fewer instructions are executed.... Sep 18 22:21:37 I understand how it works I was wondering about numbers Sep 18 22:21:39 ....but all at a cost of ASLR, which can be a deal breaker for some products... Sep 18 22:21:58 If you can find the slides from Berlin YP dev day advanced, they should be there Sep 18 22:22:07 ok Sep 18 22:23:33 loading busybox on x86-64... 93 less relocs, 71 more cache hits, 1201 fewer rel relocs.. Sep 18 22:23:52 relocation time was 13595365 cycles -faster w/ the prelimker Sep 18 22:24:04 ok Sep 18 22:24:06 the overall obj loat time was 18293460 cycles faster Sep 18 22:24:14 (this was against 2.2 BTW) Sep 18 22:24:25 simply enabel 'LD_DEBUG=statistics' to ocmpare Sep 18 22:24:46 this is good for systems which reboot/load/unload apps often Sep 18 22:25:01 yes Sep 18 22:25:24 fast(er) boot times and/or lots of app load/unload Sep 18 22:25:53 lets see.. Sep 18 22:26:16 second page.. x86-64 again.. 4.9s less time to 'boot,, login, type free, and finish a halt' Sep 18 22:26:33 not I typed these by hand so there was some variation, but I did 3 runs and averaged them Sep 18 22:26:41 that was core-image-minimal Sep 18 22:26:51 core-image-base was 7.6 second faster booting.. Sep 18 22:27:09 arm core-image base was 8 seconds faster Sep 18 22:27:29 did you disable console logs ? Sep 18 22:27:35 no Sep 18 22:27:42 may be you should Sep 18 22:28:02 I just selected the BSP (qemuarm), the image.. and ran base don that.. Sep 18 22:28:05 no additional tuning Sep 18 22:28:35 i see qemuarm will have quite different characteristic Sep 18 22:28:54 lol, ya it's faster then most real CPUs.. ;) Sep 18 22:29:09 something like beaglebone or rpi might give better peek Sep 18 22:29:11 the x86-64 is a more realistic test as the hardware is the same Sep 18 22:29:47 at the time I compared qemuarm and an a9 version, and they were roughly the same.. so I settled on the stock qemuarm Sep 18 22:30:30 ok Sep 18 22:30:44 musl would be interesting benchmark for smaller systems Sep 18 22:31:02 since its quite frugal on memory things will be different Sep 18 22:31:06 yes.. I don't think the work on the musl side would be too bad.. but I've got no time to even play there.. Sep 18 22:31:21 but it does not have lazy binding Sep 18 22:31:28 so prelink might help Sep 18 22:31:41 the prelinker itself is generally agnostic to libc.. but does try to do some basic ld-so name checking.. which of course fails due to musl Sep 18 22:31:51 hmm Sep 18 22:32:13 ya, I was looking and lazy binding didn't seem to do that much in the simple tests I ran.. the lazy binding pieces of glibc didn't hit very often... Sep 18 22:32:29 but again, my test was very simple.. Sep 18 22:33:31 you should use some real loads like qtwebkit or chromium apps Sep 18 22:34:08 I was a lot more interested in boot performance.. vs those.. Sep 18 22:34:21 customers I use don't do chromium or qt much.. Sep 18 22:34:50 they're worried about servers, routers, etc.. so boot performance and overall memory usage was a much bigger issue Sep 18 22:36:17 use busybox init and you cant beat the boot speed. Sep 18 22:36:31 applet architecture means no fork/execs Sep 18 22:36:45 shell scripts are 10times quick to execute Sep 18 22:37:00 I don't remember if this was sysvinit or systemd.. Sep 18 22:37:13 but it was not the busybox one.. I did not customize it at all Sep 18 22:37:28 (I suspect it was busybox, but it's not in the few notes I still have) Sep 18 22:37:36 systemd shoves quite a bit of data and becomes memory bus bound Sep 18 22:37:37 'er.. I suspect it was -systemd- I mean Sep 18 22:52:31 sorry, I was told we are not using plink anymore.. this was seen on pyro build. I suspect I have an un-clean build env Sep 18 23:22:31 hey Sep 18 23:23:12 is it possible to install files from deploydir/deploy_image_dir to the actual rootfs? Sep 18 23:23:54 i'm trying to install files put into deploydir by u-boot into a special partition instead of having them installed to /boot Sep 19 00:40:37 I guess you must be using custom image task then you can do it in there too Sep 19 00:40:54 artifacts in deploydir are generally for final consumption **** ENDING LOGGING AT Tue Sep 19 03:00:01 2017