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.
> >
> >
