Bug#944589: gsequencer: stalls system
Hi,
This one liner patch would reduce CPU usage from 300 % to 100 %.
cheers,
Joël
On Thu, Nov 28, 2019 at 5:35 AM Joël Krähemann <jkraehemann@gmail.com> wrote:
>
> Hi,
> Just checked the CPU usage again as running the AgsDrum sequencer,
> during playback the usage goes down to 80 %.
>
> I think with a small patch we can fix this behavior.
>
> regards,
> Joël
>
> On Thu, Nov 28, 2019 at 4:26 AM Joël Krähemann <jkraehemann@gmail.com> wrote:
> >
> > 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
--- ags/audio/thread/ags_audio_loop.c.orig 2019-11-28 05:36:31.193891132 +0100
+++ ags/audio/thread/ags_audio_loop.c 2019-11-28 05:41:30.577544805 +0100
@@ -945,6 +945,8 @@
export_thread = g_atomic_pointer_get(&(export_thread->next));
}
+
+ usleep(USEC_PER_SEC / thread->freq - 4);
}
}
Reply to: