On Wed, 2018-02-14 at 11:53 -0800, Zac Medico wrote: On 02/14/2018 07:49 AM, Joakim Tjernlund wrote: > We got an embedded target which we upded with binary pks(157 in this case) > using: > PKGDIR=/opt/fs/osappl04a-r30b-1/usr/portage/packages emerge > --rebuilt-binaries --verbose --usepkgonly -NDu @world @cusfpv3 > and this takes forever, about 1 hour > > not sure where to start looking for a cause, is this known for ppc32 ?
No, I haven't seen any reports like this. Tested on my x86_64 DE and I find binary pkg install slow there too. The load stays between 1-2 there as well. There is something odd going on I think. > I got btrfs root FS on 4 core, 1.3 GHz CPU on eMMC media. The rw performance > is decent I think. > load avg. about 1.1 so no CPU is not limiting. > sys-apps/portage: > Installed versions: 2.3.19-r1(17:41:24 24/01/18)(ipc native-extensions > xattr -build -doc -epydoc -selinux LINGUAS="-ru" PYTHON_TARGETS="python2_7 > python3_4 -pypy -python3_5 -python3_6") > > Is there some I can speed up binary pkg emerge? > when stracing I see way too many system calls > but this one stands out, 1 byte reads: > > 17750 16:39:40 brk(0x100d7000) = 0x100d7000 > 17750 16:39:40 brk(0x100d6000) = 0x100d6000 > 17750 16:39:40 read(0, "d", 1) = 1 > 17750 16:39:40 read(0, "e", 1) = 1 > 17750 16:39:40 read(0, "c", 1) = 1 > 17750 16:39:40 read(0, "l", 1) = 1 > 17750 16:39:40 read(0, "a", 1) = 1 > 17750 16:39:40 read(0, "r", 1) = 1 > 17750 16:39:40 read(0, "e", 1) = 1 > 17750 16:39:40 read(0, " ", 1) = 1 > 17750 16:39:40 read(0, "-", 1) = 1 > 17750 16:39:40 read(0, "x", 1) = 1 > 17750 16:39:40 read(0, " ", 1) = 1 > 17750 16:39:40 read(0, "A", 1) = 1 > 17750 16:39:40 read(0, "=", 1) = 1 > 17750 16:39:40 read(0, "\"", 1) = 1 > .... > 17750 16:39:43 read(0, "t", 1) = 1 > 17750 16:39:43 read(0, "\n", 1) = 1 > 17750 16:39:43 read(0, "}", 1) = 1 > 17750 16:39:43 read(0, "\n", 1) = 1 > 17750 16:39:43 read(0, "", 1) = 0 > 17750 16:39:43 write(1, " function _eapply_patch () \n "..., 4345) = 4345 I see what's causing those 1 byte reads, I've filed this bug: https://bugs.gentoo.org/647654 Nice, one down!
