| 00:06.11 | *** join/#oe micka (~micka@81-67-57-137.rev.numericable.fr) |
| 00:49.47 | *** join/#oe micka (~micka@81-67-57-137.rev.numericable.fr) |
| 01:05.48 | *** join/#oe micka (~micka@81-67-57-137.rev.numericable.fr) |
| 01:19.47 | *** join/#oe micka (~micka@81-67-57-137.rev.numericable.fr) |
| 01:35.19 | *** join/#oe micka (~micka@81-67-57-137.rev.numericable.fr) |
| 01:51.20 | *** join/#oe micka (~micka@81-67-57-137.rev.numericable.fr) |
| 02:06.33 | *** join/#oe Varti (~varthall@dynamic-adsl-78-12-171-14.clienti.tiscali.it) |
| 02:32.54 | *** join/#oe snowkidind (~textual@216.15.40.124) |
| 02:37.19 | *** join/#oe sgw (~swold@c-73-180-42-186.hsd1.or.comcast.net) |
| 02:42.13 | *** join/#oe sgw (swold@nat/intel/x-qfutwxnltzjivmck) |
| 02:51.27 | *** join/#oe micka (~micka@81-67-57-137.rev.numericable.fr) |
| 03:08.22 | *** join/#oe Nilesh_ (uid116340@gateway/web/irccloud.com/x-hxwwpdtyjuwdqmcz) |
| 03:38.29 | *** join/#oe m4t (~matt@2604:180:0:5d2::bad:beef) |
| 03:49.59 | *** join/#oe micka (~micka@81-67-57-137.rev.numericable.fr) |
| 04:35.03 | *** join/#oe micka (~micka@81-67-57-137.rev.numericable.fr) |
| 04:51.34 | *** join/#oe micka (~micka@81-67-57-137.rev.numericable.fr) |
| 05:05.36 | *** join/#oe micka (~micka@81-67-57-137.rev.numericable.fr) |
| 05:13.15 | *** join/#oe AndersD (~anders@194-237-220-218.customer.telia.com) |
| 05:28.29 | *** join/#oe AndersD (~anders@194-237-220-218.customer.telia.com) |
| 05:28.44 | *** join/#oe hmwel (~hmw@zimbra.welvaarts.com) |
| 05:33.45 | *** join/#oe Marex (~Marex@195.140.253.167) |
| 05:51.10 | *** join/#oe micka (~micka@81-67-57-137.rev.numericable.fr) |
| 06:12.39 | *** join/#oe t0mmy (~tprrt@ram31-1-82-234-79-177.fbx.proxad.net) |
| 06:22.13 | *** join/#oe micka (~micka@81-67-57-137.rev.numericable.fr) |
| 06:30.55 | *** join/#oe yegorich (~yegorich@mail.visionsystems.de) |
| 06:36.14 | *** join/#oe micka (~micka@81-67-57-137.rev.numericable.fr) |
| 06:52.15 | *** join/#oe micka (~micka@81-67-57-137.rev.numericable.fr) |
| 06:54.37 | *** join/#oe rob_w (~bob@93.104.205.194) |
| 06:54.38 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
| 06:55.14 | *** join/#oe morphis (~morphis@p57ABFD33.dip0.t-ipconnect.de) |
| 07:01.55 | *** join/#oe diego_r (~diego@host57-224-static.7-79-b.business.telecomitalia.it) |
| 07:06.11 | *** join/#oe jbrianceau_away (uid10952@gateway/web/irccloud.com/x-uwfmmojxurtnozam) |
| 07:13.37 | *** join/#oe frsc (~frsc@80.149.173.68) |
| 07:14.04 | *** join/#oe tom_nov (~Tomas@176.74.132.138) |
| 07:20.25 | *** join/#oe AndersD (~anders@194-237-220-218.customer.telia.com) |
| 07:35.39 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 07:40.28 | *** join/#oe Bunio_FH (~bunio@89-73-217-90.dynamic.chello.pl) |
| 08:02.37 | *** join/#oe JaMa (~martin@217.30.68.212) |
| 08:04.22 | *** join/#oe t0mmy (~tprrt@217.114.201.133) |
| 08:08.04 | *** join/#oe nslu2-log (~nslu2-log@milla.nas-admin.org) |
| 08:15.11 | *** join/#oe yann (~yann@LFbn-1-3552-118.w90-127.abo.wanadoo.fr) |
| 08:20.25 | *** join/#oe micka (~micka@81-67-57-137.rev.numericable.fr) |
| 08:23.05 | *** join/#oe rburton (~textual@home.burtonini.com) |
| 08:24.04 | *** join/#oe rburton (~textual@home.burtonini.com) |
| 08:29.10 | *** join/#oe rovanceo (~rovanceo@80.97.64.55) |
| 08:29.37 | *** join/#oe eduardas_m (~eduardas@213.197.143.19) |
| 08:31.16 | *** join/#oe ao2 (~ao2@host145-137-dynamic.56-79-r.retail.telecomitalia.it) |
| 08:42.09 | *** join/#oe rburton (~textual@home.burtonini.com) |
| 09:57.49 | *** join/#oe koen (~koen@185.47.135.167) |
| 09:57.50 | *** join/#oe koen (~koen@linaro/koen) |
| 10:07.06 | *** join/#oe micka (~micka@81-67-57-137.rev.numericable.fr) |
| 10:26.51 | *** join/#oe joseppc (~josep@sestofw01.enea.se) |
| 10:26.51 | *** join/#oe joseppc (~josep@linaro/joseppc) |
| 10:48.24 | *** join/#oe ant_work (~ant__@95.236.251.119) |
| 11:36.24 | *** join/#oe rovanceo (~rovanceo@80.97.64.55) |
| 11:42.35 | *** join/#oe ldnunes (~ldnunes_@181.220.79.73) |
| 11:52.06 | *** join/#oe mago1 (~mago@h-225-157.A444.priv.bahnhof.se) |
| 12:02.13 | *** join/#oe bradfa (~andrew@clr-vpn01.kodakalaris.com) |
| 12:06.10 | *** join/#oe micka (~micka@81-67-57-137.rev.numericable.fr) |
| 12:06.46 | *** join/#oe koen (~koen@185.47.135.167) |
| 12:06.47 | *** join/#oe koen (~koen@linaro/koen) |
| 12:08.55 | *** join/#oe ant_work (~ant__@host18-113-dynamic.16-79-r.retail.telecomitalia.it) |
| 12:54.57 | *** join/#oe rovanceo (~rovanceo@80.97.64.55) |
| 13:07.15 | *** join/#oe micka (~micka@81-67-57-137.rev.numericable.fr) |
| 13:23.15 | *** join/#oe micka (~micka@81-67-57-137.rev.numericable.fr) |
| 13:31.34 | Crofton | I see a lot of HOMEPAGE commits, any background I missed? |
| 13:37.16 | *** join/#oe micka (~micka@81-67-57-137.rev.numericable.fr) |
| 13:53.18 | *** join/#oe micka (~micka@81-67-57-137.rev.numericable.fr) |
| 14:21.11 | *** join/#oe t0mmy (~tprrt@217.114.201.133) |
| 14:27.15 | *** join/#oe snowkidind (~textual@216.15.40.124) |
| 14:30.22 | *** join/#oe bmouring (~bmouring@130.164.62.149) |
| 14:32.33 | *** join/#oe morphis (~morphis@p57ABFD33.dip0.t-ipconnect.de) |
| 14:38.24 | *** join/#oe stephano (~stephano@134.134.139.83) |
| 14:45.04 | rburton | Crofton: WR is filling them in, no doubt they have a reason |
| 14:45.24 | fray | the recent patches were from Fujitsu |
| 14:45.41 | fray | WR does them as part of the regular recipe maintenance.. but we don't usually add new ones to recipes we don't maintain. |
| 14:45.50 | fray | The layerindex does pay attention to things like homepage.. |
| 14:46.01 | fray | So if someone is using it to lookup recipes, it is useful |
| 14:46.55 | fray | http://layers.openembedded.org/layerindex/recipe/81/ |
| 14:46.59 | fray | i.e. homepage is listed |
| 14:49.47 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 14:49.52 | *** join/#oe bmouring (~bmouring@130.164.62.149) |
| 14:50.19 | *** join/#oe hrw (~hrw@redhat/hrw) |
| 15:04.08 | *** join/#oe sgw (~swold@134.134.139.83) |
| 15:08.54 | *** join/#oe micka (~micka@81-67-57-137.rev.numericable.fr) |
| 15:14.41 | *** join/#oe rburton (~textual@home.burtonini.com) |
| 15:20.58 | Crofton | Thanks guys! |
| 15:23.56 | *** join/#oe micka (~micka@81-67-57-137.rev.numericable.fr) |
| 15:31.17 | armpit | fray, do you need those HOMEPAGE changes back ported? |
| 15:31.43 | fray | don't look at me.. I didn't make them |
| 15:31.59 | rburton | armpit: if you can be bothered i guess :) |
| 15:32.03 | fray | We just keep them updated in recipes we support.. since updated recipes don't usually get backports, not a problem |
| 15:32.16 | fray | As I said, Fujitsu is the one that has been sending updates recently |
| 15:32.33 | rburton | why did i think it was WR? :) |
| 15:33.02 | fray | huangqy.fnst@cn.fujitsu.com |
| 15:33.31 | fray | (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) |
| 15:34.51 | armpit | ah, mistaken the sender was from WR without looking at the email adder |
| 15:35.51 | vmeson | rburton: if you like WR could reformat all recipes to be more consistent and add decorator comments and a style checker! :-P |
| 15:36.10 | rburton | haha no thanks |
| 15:36.11 | fray | Randy, you should get right on that.. ;) |
| 15:36.15 | vmeson | heh |
| 15:37.56 | *** join/#oe micka (~micka@81-67-57-137.rev.numericable.fr) |
| 15:39.04 | *** join/#oe tbr (dm8tbr@mail.bfst.de) |
| 15:48.01 | *** join/#oe stephano (stephano@nat/intel/x-uqstuqzsewccrkpn) |
| 15:50.17 | *** join/#oe stefan_schmidt (~stefan@p20030048093AC7819A8389FFFE2E3FAE.dip0.t-ipconnect.de) |
| 16:00.17 | *** join/#oe Varti (~varthall@dynamic-adsl-78-12-171-14.clienti.tiscali.it) |
| 16:16.13 | *** join/#oe morphis_ (~morphis@p57ABFC38.dip0.t-ipconnect.de) |
| 16:17.22 | *** join/#oe eFfeM (~frans@f160137.upc-f.chello.nl) |
| 16:34.27 | *** join/#oe stephano (~stephano@134.134.139.83) |
| 16:41.50 | *** join/#oe florian (~florian_k@Maemo/community/contributor/florian) |
| 16:45.18 | *** join/#oe blight (~greg@80-109-132-21.cable.dynamic.surfer.at) |
| 16:45.18 | *** join/#oe blight (~greg@reactos/developer/blight) |
| 16:52.41 | *** join/#oe Bunio_FH (~bunio@clj-165.netdrive.pl) |
| 17:03.24 | *** join/#oe bpittman (~bill@130.164.62.212) |
| 17:10.56 | *** join/#oe rburton (~textual@home.burtonini.com) |
| 17:57.42 | *** join/#oe khem (~khem@unaffiliated/khem) |
| 18:00.20 | *** join/#oe yann (~yann@nan92-1-81-57-214-146.fbx.proxad.net) |
| 18:53.34 | *** join/#oe t0mmy (~tprrt@ram31-1-82-234-79-177.fbx.proxad.net) |
| 19:28.01 | *** join/#oe behanw (uid110099@gateway/web/irccloud.com/x-qgfrpbofljpqigdc) |
| 19:58.45 | *** join/#oe micka (~micka@81-67-57-137.rev.numericable.fr) |
| 19:59.02 | *** join/#oe stephano (~stephano@134.134.139.72) |
| 20:00.05 | *** join/#oe khem (~khem@unaffiliated/khem) |
| 20:01.54 | *** join/#oe khem (~khem@unaffiliated/khem) |
| 20:04.51 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 20:27.27 | *** join/#oe ant_home (~ant__@host224-10-dynamic.249-95-r.retail.telecomitalia.it) |
| 20:33.24 | *** part/#oe adelcast (~adelcast@130.164.62.108) |
| 20:40.32 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 20:54.13 | *** join/#oe adelcast (~adelcast@130.164.62.108) |
| 21:05.05 | *** join/#oe stephano (~stephano@134.134.139.72) |
| 21:07.49 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 21:25.22 | *** join/#oe adelcast (~adelcast@130.164.62.108) |
| 21:36.02 | armpit | wow, got prelink to coredump |
| 21:38.24 | rburton | oh thats not hard :) |
| 21:43.24 | *** join/#oe stephano (~stephano@134.134.139.72) |
| 21:44.07 | armpit | during build? |
| 21:45.44 | armpit | cleans up build |
| 21:57.27 | khem | do we still need prelink in 2017 |
| 21:59.23 | rburton | fray insists that it is still useful :) |
| 21:59.31 | rburton | asked that when it last broke |
| 22:00.34 | khem | really, well may be |
| 22:01.07 | fray | 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. |
| 22:01.22 | fray | it really was the difference between meeting memory and boot performance requirements or not |
| 22:01.23 | khem | which arm |
| 22:01.40 | fray | 32-bit |
| 22:01.47 | fray | 64-bit is only partially impleented |
| 22:01.47 | khem | we have 64bit AMBA interconnect now a day s |
| 22:02.03 | fray | if someone can help me finish implementing the 64-bit support, I could instrument that.. |
| 22:02.38 | fray | 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') |
| 22:03.47 | fray | 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 |
| 22:04.43 | fray | (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) |
| 22:05.11 | fray | (there are some custom firmware for x86 that can make it so boot performance actually matters.. but they are fairly rare still) |
| 22:14.55 | khem | how much speedup does prelinker result in on avg |
| 22:15.41 | khem | can it work with PIE executables ? |
| 22:17.02 | fray | 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.. |
| 22:17.06 | fray | (Sorry I don't have figures handy) |
| 22:17.37 | fray | I BELIEVE PIE works, but the downside is it effectively determines load address/run address prior to run-time.. which avoids ASLR and such |
| 22:18.40 | fray | 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) |
| 22:19.43 | fray | 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) |
| 22:20.08 | fray | 2) less power usage (for loading) because fewer instructions are executed.... |
| 22:21.37 | khem | I understand how it works I was wondering about numbers |
| 22:21.38 | fray | ....but all at a cost of ASLR, which can be a deal breaker for some products... |
| 22:21.58 | fray | If you can find the slides from Berlin YP dev day advanced, they should be there |
| 22:22.07 | khem | ok |
| 22:23.33 | fray | loading busybox on x86-64... 93 less relocs, 71 more cache hits, 1201 fewer rel relocs.. |
| 22:23.52 | fray | relocation time was 13595365 cycles -faster w/ the prelimker |
| 22:24.04 | khem | ok |
| 22:24.06 | fray | the overall obj loat time was 18293460 cycles faster |
| 22:24.14 | fray | (this was against 2.2 BTW) |
| 22:24.25 | fray | simply enabel 'LD_DEBUG=statistics' to ocmpare |
| 22:24.46 | khem | this is good for systems which reboot/load/unload apps often |
| 22:25.01 | fray | yes |
| 22:25.24 | fray | fast(er) boot times and/or lots of app load/unload |
| 22:25.53 | fray | lets see.. |
| 22:26.16 | fray | second page.. x86-64 again.. 4.9s less time to 'boot,, login, type free, and finish a halt' |
| 22:26.33 | fray | not I typed these by hand so there was some variation, but I did 3 runs and averaged them |
| 22:26.41 | fray | that was core-image-minimal |
| 22:26.51 | fray | core-image-base was 7.6 second faster booting.. |
| 22:27.09 | fray | arm core-image base was 8 seconds faster |
| 22:27.29 | khem | did you disable console logs ? |
| 22:27.35 | fray | no |
| 22:27.42 | khem | may be you should |
| 22:28.02 | fray | I just selected the BSP (qemuarm), the image.. and ran base don that.. |
| 22:28.05 | fray | no additional tuning |
| 22:28.35 | khem | i see qemuarm will have quite different characteristic |
| 22:28.54 | fray | lol, ya it's faster then most real CPUs.. ;) |
| 22:29.09 | khem | something like beaglebone or rpi might give better peek |
| 22:29.11 | fray | the x86-64 is a more realistic test as the hardware is the same |
| 22:29.47 | fray | at the time I compared qemuarm and an a9 version, and they were roughly the same.. so I settled on the stock qemuarm |
| 22:30.30 | khem | ok |
| 22:30.45 | khem | musl would be interesting benchmark for smaller systems |
| 22:31.03 | khem | since its quite frugal on memory things will be different |
| 22:31.06 | fray | 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.. |
| 22:31.21 | khem | but it does not have lazy binding |
| 22:31.28 | khem | so prelink might help |
| 22:31.40 | fray | 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 |
| 22:31.51 | khem | hmm |
| 22:32.13 | fray | 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... |
| 22:32.29 | fray | but again, my test was very simple.. |
| 22:33.31 | khem | you should use some real loads like qtwebkit or chromium apps |
| 22:34.08 | fray | I was a lot more interested in boot performance.. vs those.. |
| 22:34.21 | fray | customers I use don't do chromium or qt much.. |
| 22:34.50 | fray | they're worried about servers, routers, etc.. so boot performance and overall memory usage was a much bigger issue |
| 22:36.18 | khem | use busybox init and you cant beat the boot speed. |
| 22:36.32 | khem | applet architecture means no fork/execs |
| 22:36.45 | khem | shell scripts are 10times quick to execute |
| 22:37.00 | fray | I don't remember if this was sysvinit or systemd.. |
| 22:37.13 | fray | but it was not the busybox one.. I did not customize it at all |
| 22:37.28 | fray | (I suspect it was busybox, but it's not in the few notes I still have) |
| 22:37.36 | khem | systemd shoves quite a bit of data and becomes memory bus bound |
| 22:37.37 | fray | 'er.. I suspect it was -systemd- I mean |
| 22:43.22 | *** join/#oe georgem_home (uid210681@gateway/web/irccloud.com/x-mhfzhtvwyfxmocei) |
| 22:52.31 | armpit | 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 |
| 23:22.31 | domme | hey |
| 23:23.12 | domme | is it possible to install files from deploydir/deploy_image_dir to the actual rootfs? |
| 23:23.54 | domme | i'm trying to install files put into deploydir by u-boot into a special partition instead of having them installed to /boot |
| 23:43.03 | *** join/#oe stephano (stephano@nat/intel/x-nmuimcyhasesvihz) |
| 23:58.12 | *** join/#oe sgw (~swold@134.134.139.83) |