Re: [gentoo-portage-dev] emerging binary pkgs very slow on ppc32

[Joakim Tjernlund]

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!