[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 100% cpu load with idle octave on ARM

From: nfb
Subject: Re: 100% cpu load with idle octave on ARM
Date: Wed, 27 May 2015 19:47:42 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

On Wed, May 27, 2015 at 01:03:30PM +0200, nfb wrote:
> Hi list,
> i'm reporting here an issue i already exposed on the IRC channel, but maybe
> this is a better place for such things.
> I'm running octave on an ARM chromebook with debian testing installed on it,
> and octave 3.8.2 (the default one [0] packaged in the debian testing repos).
> As soon as i start octave in the terminal, with "octave-cli" command, i can
> see with top (the process monitoring tool) that the octave-cli process is
> eating 100% of the cpu, and with htop i see that it is using one core of the
> two available at 100%. All this without performing calculations or any other
> action, just starting octave and leaving it idling in a terminal window
> prompting for user input.
> I don't know which specific informations you need to try to debug this, so let
> me know and i'll reply as soon as possible.
> For the record, i'm running the same version packaged for i386 and everything
> is fine.
> Thanks.
> nfb
> [0]

Finally we found the problem and the corresponding solution, so i write it
here for the benefit of other users. Sorry for any eventual inaccuracy.

I got help in the #octave IRC channel this afternoon. I first run strace on
octave-cli, and it was showing a really insane amount of gettimeofday()
calls, but due to my setup and my older 3.8 kernel we couldn't use perf to
analyze the situation in depth, since debian doesn't ship a package for it.
I was just about to compile it from scratch (ignoring how much time/effort it
could have taken) when, after some speculations, one of the guys helping me,
realized that since octave-cli is not multithreaded, then a 100% cpu usage AND
a command prompt (as in my case), means that something is being executed by
some third party libraries, so suddenly i was asked which BLAS backend i was
using. I had openblas installed, so we tried switching to the implementation
provided by the packages libblas3 and liblapack3, and after updating debian
alternatives to let octave use these ones instead of openblas boom... no more
100% load on the cpu.
Under suggestion of another guy i was told to try the ATLAS implementation,
since, if it doesn't give problems, it's faster than the libblas3 and
liblapack3 implementations. So after installing the libatlas3-base package,
and updating alternatives again, it seems there are no issues running with
atlas, and for now i'm sticking with it.
So, in case you are facing the same issue on an ARM platform, double check if
you are using openblas and if it's the one giving problems.

I'd like to thank mtmx, andy1978, fmost and JordiGH for the direct support,
and all other guys involved in the octave project.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]