[LAD] cpu spikes

Len Ovens len at ovenwerks.net
Mon Jan 25 14:50:06 UTC 2016


On Mon, 25 Jan 2016, Jörn Nettingsmeier wrote:

> sorry to hijack this thread, but: when enquiring about latency tuning, one 
> frequently encounters hints like "disable cron", "disable indexing services", 
> "disable this, disable that".
>
> however, none of those alleged culprits run with real-time privileges or 
> access driver or kernel code which does. so how can they be a problem (and 
> disabling them part of the solution)? i'm asking because i've got my own 
> anecdotal evidence that it *does* make a difference...

Yes, the big thing is that I see xruns just before something pops up 
saying "hey theres an upgrade available". Now as I have said, cron runs 
super "nice" and so anything that cron runs should be really low priority 
too. But time constraints are not just CPU access and time. I would think 
that the network driver even using the bus for a full 1500 bytes should 
not be a problem, but where does that data go? What priority is a disk 
access... and once it starts how big a chunk of data gets written and is 
it atomic? It does not seem to be memory related as I use half my memory 
it seems even running a lot of stuff at the same time. My swap after weeks 
of running is still 0%. (swappiness 10)

> i understand how device drivers can be nasty (graphics cards locking up the 
> pci bus, wifi chips hogging the kernel for milliseconds at a time or

Actually I think with wifi chips it is the bus that gets hogged.

> worse...) but it seems that a) either kernel preemption and real-time 
> scheduling is terribly buggy or hand-wavey, or b) we're feeding each other 
> snake-oil in recommending to disable userspace things that is running without 
> rt privs.

As you yourself can attest, it does make a difference. I would suggest 
that there are some kernel drivers that are optimized for throughput over 
latency that have not yet been accounted for. Or some other things that 
are in their own way time constrained. Network traffic comes to mind. 
Network traffic comes when it comes and can only be buffered in hardware 
so long before packets get lost. However, as I said, even full packets are 
relatively small. What is the biggest data chunk that gets written to 
disk? Has anyone gone through kernel drivers looking for atomic parts that 
could be shortened? Is there a setting for maximum data size of a disk 
write/read? It appears there are ways to throttle disk access speed on a 
per-proccess basis.

Another one that is puzzling is CPU speed changes (AKA OnDemand). These 
happen very fast and should not cause trouble, but they do. It seems to 
me, just by watching a cpu speed monitor, that xruns happen at the point 
the cpu speed goes down only. Perhaps there is some timing loop somewhere 
that gets expanded that should not. I would think any timing should be 
done by timers that are not cpu speed dependant.

Honestly, these are just thoughts off the top of my head. I don't know the 
kernel code well enough to say (Means I have not looked at it). I just 
know that by turning certain things off, I can get lower latency without 
xruns over a 24hour period. (even just sitting idle streaming zeros)

--
Len Ovens
www.ovenwerks.net


More information about the Linux-audio-dev mailing list