Bug#944589: gsequencer: stalls system
Hi,
I take your complain about CPU usage serious. I intend to target it
in GSequencer v2.4.x
The high CPU usage is due to AgsThreadPool providing non-blocking
calls to AgsTaskThread.
But I don't see any way to provide it to buster.
If you are interested in what is going on related to the thread API,
here are further informations:
http://savannah.nongnu.org/forum/forum.php?forum_id=9601
sorry,
Joël
On Thu, Nov 28, 2019 at 3:26 AM Joël Krähemann <jkraehemann@gmail.com> wrote:
>
> Hi,
> Yes, it is true. GSequencer consumes too much power as doing no audio
> processing.
> This was targeted with next major release v3.0.0 expected available
> within a half year.
>
> To change this behavior, I had to refactor the threading API of
> GSequencer. Currently
> it creates many threads without running any audio processing.
>
> The thread pool is the main cause for this, which is used by AgsTaskThread.
>
> In GSequencer v3.0.0 the AgsTask objects are launched in GMainContext. But for
> now they run asynchronous exclusive and are added by a non-blocking call.
>
>
> On Thu, Nov 28, 2019 at 2:00 AM westlake <westlake2012@videotron.ca> wrote:
> >
> > Here when I use gsequencer, (pasuspender not needed)
> > LADSPA_PATH="" DSSI_PATH="" LV2_PATH="" gsequencer
> >
> > I can run skipping the plugin-scan, I can get the graphical interface
> > within a second...
> >
> > dragging the window skimps as this app is not throttling it's cpu
> > utilization correctly..
> >
> > When using "top", the app is using 300%...
> >
> > The limits setting /etc/security/limits.conf::
> > (for security limits.conf, I comment-out everything in
> > /etc/security/limits.d/ to keep the configuration easier to read)
> > ""
> > * hard core 0
> > * hard nofile 1048576
> > * hard rtprio 95
> > * - memlock unlimited
> > * - msgqueue 65536
> > * - nice -19
> > * - nice -20
> > * - rttime 100000
> > * soft core 0
> > * soft nofile 1048576
> > * soft rtprio 95
> > @users - priority 0
> > ""
> >
> > changed rtprio to 35, and "top"(command) still says gsequencer is using
> > 300% even after reboot.
> > "* hard rtprio 95
> > * soft rtprio 95"
> > "* hard rtprio 35
> > * soft rtprio 35"
> >
> >
> > The observation when rtprio is set at 95-> majority of threads go at
> > FIFO 95. [ screenshot provided ]
> >
> > The observation when rtprio is set at 35-> all threads are set to
> > SCHED_OTHER and only one gets set at FIFO with priority 20.
> >
> > 'jack' for both rtprio cases in ags' settings, 1 reboot with the
> > different rtprio settings. So the rtprio gets set aggressively with 95,
> > but barely nothing set with 35. << buggy.
> >
> > More buggy because with both rtprio settings the cpu is still at 300%.
> >
> > --> ags should be down at 2-5% when it is not doing any work.
> >
> > When I look at an RT-driven application such as ardour, while it runs it
> > does spike in cpu it immediately goes back down to 5%.
> >
> > ..also the rt-safe option in ags doesn't do anything. cpu% is still
> > spiked high..
>
> The RT-safe option does reduce the calls to malloc().
>
> >
> > Other observation:
> > When ags is set at alsa, the cpu% is lower but it is still very high at
> > 110%.
> >
> > The threads with the alsa setting show 0.3% cpu utilization instead of
> > 10% when ags is set to jack.. the "main" process I suppose is the one
> > that is always going 100+% for both alsa and jack cases.
> >
> > quick summary::
> > Alsa (top without -H) --> 110%
> > Jack (top without -H) --> 300%
> >
> > When it says 100+%, ags is using more than 1 core..
> >
> > With jack, 3 cores are now bogged down.. That tells me there is
> > something very wrong.
> >
> > I can now see what is happening... there's a bug because gsequencer is
> > doing no work but it polls the cpu at 100%-300%...
>
> There many threads running. Especially AgsThreadPoll creates some
> threads that might be used.
>
> >
> > The cpu% is still grabbed even when I change kernel.sched_rt_runtime_us
> > = 950000 to 500000
> >
> > so there's a serious violation of scheduling policy happening here with
> > RT kernels for this software.
>
> What scheduling policy are you talking about?
>
> >
> > ..
> > I also don't know what makes you think pulseaudio is being used, here I
> > have it masked under ~/.config/systemd/user .. Jackdbus here is also
> > not handled by the dbus-auto-activation,...
> >
> > ~/.local/share/dbus-1/services/org.jackaudio.service
> > "
> > [D-BUS Service]
> > Name=org.jackaudio.service
> >
> > SystemdService=dbus-org.jackaudio.service
> > "
> >
> > ~/.config/systemd/user/dbus-org.jackaudio.service -- allows the user to
> > enable/disable jackdbus and whether to have it auto-start or not.. This
> > is user-defined startup unit file and is what I use here to stop jack as
> > needed.
> >
> > pulseaudio cannot be autostarted because it is masked..
> >
> > ls ~/.config/systemd/user/
> > pulseaudio.service -> /dev/null
> > pulseaudio.socket -> /dev/null
> >
> > things in ~/.config/systemd/user override things in /usr/lib/systemd/user/
> > /usr/lib/systemd/user/pulseaudio.service
> > /usr/lib/systemd/user/pulseaudio.socket
> >
> > there may be a "pulse" entry in "aplay -L", but its a dormant entry as
> > "pgrep -fa pulseaudio" and "pacmd" do not show no pulseaudio ever gets
> > loaded...
> >
> > For security/audit team:
> > Ags-> 2 megabytes, uses 300% of the cpu cores.
> > Ardour-> a 100+ megabyte application uses just 5%.
> >
>
> What makes you think memory usage has anything to do with CPU
> consumption?
>
> > This package severely ignores scheduling restrictions. --- its' the only
> > RT audio application on debian that violates and ignores settings in
> > both /etc/security/limits.conf and /etc/sysctl.d/ for
> > kernel.sched_rt_runtime_us.
>
> So you think I should parse these files?
>
> >
> > This package may be better to have removed for now, as it seriously
> > violates scheduling of the kernel. Possibly more than just rt-kernels.
> >
>
> I see no reason for this.
>
> > thanks
Reply to: