Thank you for the advice. I will try the patch, but I want to let the current php build complete, which may take a few more days.
Did you get the bme code I sent you? -----Original Message----- From: Artturi Alm <[email protected]> Sent: May 2, 2018 3:55 PM To: [email protected] Cc: [email protected] Subject: Re: gtk libool slow on arm On Thu, May 03, 2018 at 12:26:18AM +0300, Artturi Alm wrote: > On Wed, May 02, 2018 at 10:35:27AM -0700, [email protected] wrote: > > I realize the orangepi is not the swiftest of machines, but the ld > > issue is more than just SOC performance. The ld process should > > finish within a few seconds to a minute. It is taking 20 minutes. > > > > I am trying to build php as the current bulk build failed on so many > > packages. I think it is the first bulk build since clang. The > > other compiles and processes execute in reasonable time, but when it > > comes to ld something happens. > > > > As I was looking around trying to find what some clues I ran man > > from the serial console and it hung. Man runs fine from an ssh > > connection over the lan. Man on the console was hung in bqwait. What is that? > > > > PID USERNAME PRI NICE SIZE RES STATE WAIT TIME CPU COMMAND > > 87860 root 63 0 45M 45M run - 18:26 64.60% ld > > 30014 sysadmin -6 0 832K 1556K sleep bqwait 0:10 15.23% man > > > > Later when I suspect ld finished more started to run and got stuck > > also, probably when ld started up again. > > > > PID USERNAME PRI NICE SIZE RES STATE WAIT TIME CPU COMMAND > > 18030 root 59 0 46M 47M run - 23:02 54.54% ld > > 68435 sysadmin 58 0 257M 182M run - 0:57 42.72% more > > 30014 sysadmin 10 0 832K 0K idle wait 4:14 0.00% man > > > > Both man and more seem to be using cpu cycles even though they are stuck. > > Could ld be trying to do something with the console? > > > > Hi, > > > You could also add "stty status ^T" into ~/.profile, to see what's > going on when you press it. > tbh., i've never compiled anything gtk on armv7, so i think it's > something i can't help you with. > > for less pressure on 'tty level', you could take advantage of the fifo > your hw has, with the diff below. you can see the effect with > systat(1) in the Interrupts column for com0. > > -Artturi > > Sorry, I actually sent you a old/wrong diff. correct one below. -Artturi diff --git sys/arch/armv7/dev/com_fdt.c sys/arch/armv7/dev/com_fdt.c index 053064e77c1..7fa43b25e0b 100644 --- sys/arch/armv7/dev/com_fdt.c +++ sys/arch/armv7/dev/com_fdt.c @@ -130,8 +130,11 @@ com_fdt_attach(struct device *parent, struct device *self, void *aux) sc->sc_reg_width = OF_getpropint(faa->fa_node, "reg-io-width", 4); sc->sc_reg_shift = OF_getpropint(faa->fa_node, "reg-shift", 2); - if (OF_is_compatible(faa->fa_node, "snps,dw-apb-uart")) + if (OF_is_compatible(faa->fa_node, "snps,dw-apb-uart")) { + sc->sc_uarttype = COM_UART_16550A; + sc->sc_fifolen = 64; intr = com_fdt_intr_designware; + } if (OF_is_compatible(faa->fa_node, "ti,omap3-uart") || OF_is_compatible(faa->fa_node, "ti,omap4-uart")) > > > > > -----Original Message----- > > From: [email protected] <[email protected]> On Behalf Of > > Mark Kettenis > > Sent: May 2, 2018 3:10 AM > > To: [email protected] > > Cc: [email protected]; [email protected] > > Subject: Re: gtk libool slow on arm > > > > > From: <[email protected]> > > > Date: Tue, 1 May 2018 16:30:28 -0700 > > > > > > Why is the gtk libtool so slow on arm? A typical command such as: > > > > It's not libtool, but ld, the link editor that is taking its time. > > > > > libtool: link: cc -o .libs/testentrycompletion -pthread -O2 -pipe > > > -g -Wall -Wl,-rpath-link -Wl,/usr/X11R6/lib -Wl,-rpath-link > > > -Wl,/usr/X11R6/lib testentrycompletion.o -L.libs -lgtk-3 -lgdk-3 > > > -lpangocairo-1.0 -lpango-1.0 > > > -lgobject-2.0 -lglib-2.0 -liconv -lpcre -lintl -lffi -lc++abi > > > -lgthread-2.0 -lfribidi -lm -lcairo -lpthread -lpixman-1 > > > -lfontconfig -lfreetype -lz -lexpat -lpng -lxcb-shm -lxcb > > > -lxcb-render -lXrender > > > -lX11 -lXext > > > -lpangoft2-1.0 -lharfbuzz -lgraphite2 -lgdk_pixbuf-2.0 > > > -lgmodule-2.0 > > > -lgio-2.0 -lcairo-gobject -lXinerama -lXi -lXrandr -lXcursor > > > -lXfixes -lXcomposite -lXdamage -lepoxy -latk-1.0 -latk-bridge-2.0 > > > -ldbus-1 -latspi > > > -Wl,-rpath-link,/usr/local/lib,-rpath-link,/usr/X11R6/lib > > > > That is linking in quite a number of libraries, some of which are > > fairly sizeable. > > > > > takes from 15 to 20 minutes on arm. It is all cpu time, not i/o: > > > > The binutils linker is quite crappy. The LLVM linker is better. > > > > > load averages: 2.03, 2.02, 2.00 op1bsdsnap.graf.lan > > > 16:26:21 > > > > > > 78 processes: 1 running, 76 idle, 1 on processor up 4 days, > > > 7:42 > > > > > > CPU states: 99.6% user, 0.0% nice, 0.4% system, 0.0% interrupt, > > > 0.0% idle > > > > > > Memory: Real: 59M/234M act/tot Free: 259M Cache: 98M Swap: > > > 11M/516M > > > > > > > > > > > > PID USERNAME PRI NICE SIZE RES STATE WAIT TIME CPU > > COMMAND > > > > > > 12051 root 64 0 7680K 8532K run - 6:44 99.12% ld > > > > > > 27209 sysadmin 2 0 972K 984K idle select 0:49 0.00% sshd > > > > > > 65728 _pflogd 4 0 716K 172K sleep bpf 0:29 0.00% pflogd > > > > > > I set up an i386 virtual system with one cpu at 3 GHz and the > > > whole gtk build including all the dependencies took a few hours. > > > My gtk build on an arm orangepi with a 1.2GHz cpu has been running > > > for over > > > 48 hours, all due to libtool. A cc compile finishes in seconds. > > > > The orangepi probably runs at a lower speed since DVFS isn't > > implemented yet. And the Cortex-A7 simply isn't a very powerful CPU > > as it is completely in-order. Memory bandwidth on the orangepi is probably limited as well. > > > >
