ZFS LINUX UBUNTU 22.04

[Roo432]

Does anyone know of a way to force ZFS to run at a lower CPU priority? Im not serving files or anything. I just use ZFS as a bulk drive for all my random stuff, I have compression enabled. GZIP-9. it has saved me over a full TB of storage so im keen to keep it on.

But it does cause a issue as ZFS goes to proccess data, since ZFS runs worker threads at the highest cpu priority. Every time it does it gets priority over Audio drivers and such, and cause a nasty audio cuttout in sync with the proccessing that ZFS is doing, its not that my CPU does not have the performance. I have pleanty of cycles to spare. Its just the Priority. ZFS pushes itself infront of the audio drivers constantly. and causes issues.

This is super annoying honestly, I know i should just have a secondary box doing all the compute but with my current situation that is sadly impossible.

Which leaves me to the last resort and thats lowering ZFS CPU Priority. I have also already tried the "preempt=full" trick. didnt work sadly.

 

[unwind-protect]

ZFS is all in-kernel, including the compression. I am not away of a way to set priority there.

Having said that, I am not fully convinced by your analysis that gzip is really the culprit here. It is easy to test, create z ZFS with no compression and write to it what you normally write to the gzip'ed ones and see whether the uncompressed one makes audio stutter, too. I have a hunch that it will.

You should try preempt=none. For all you know it is your audio jobs that get preempted.

And how do you do audio? Jack, pulseaudio, pipewire? Real-time priority set on the audio demon?

 

[Roo432]

currently i use Pipewire. and i just did your test.

I started writing from a SSD to the ZFS
this time it had ZERO compression impossed upon it. Same effect. audio instantly had a bad moment.

and how can i set real time priority on audio? i did alot of reading about preempt, real time kernels, etc in the past week or so trying to figure this issue out, if there is a way to make audio real time that might be very benificial!

Edit: Im actually not sure, In task manager i see Pipewire, but if i try to configure pipewire, i get a error that implies pipewire dosent exist?? i might just be a idiot, im not used to monkeying around in the backend of a OS lol

Edit edit: I just purged *everything* so that now I am DEFINITLY DEFACTO running pipewire.

 

[unwind-protect]

Here is how you configure jackd for real-time scheduling (not to be confused with the real-time kernel, this is just scheduler priorities):

How do I configure my linux system to allow JACK to use realtime scheduling? | JACK Audio Connection Kit

JACK Audio Connection Kit | How do I configure my linux system to allow JACK to use realtime scheduling?

jackaudio.org

In your place I would go one step after another to determine when the problems start:
- play an audio file in mplayer using alsa (aka no demon at all)
- if that stutters try mplayer in real-time
- if that works try moving up to jackd
- if that stutters try jackd with real-time

How do you play audio right now, anyway? Browser?

 

[Roo432]

Ah its not one specific audio source, its any audio source, games, youtube, etc.
And in regards to "JACK" looking on the website it appears it requires custom applications to use it? maybe im missing something.

Edit: i decided to try to play around with this RT business and
i went through and maually changed the priority on anyhting relating to pipewire or pulse. despite this. assuming 99 means what i think it does. It did not make a difference

 

[unwind-protect]

I would advise to try the different audio playing options (alsa, jack, pipewire) all with mplayer. The objective is to find out what component of your audio chain gets interrupted - application, demon or kernel.

 

[Roo432]

Sorry for not replying sooner got busy the past few days, it definitly still occurs with MPV player set to highest priority and the audio demon maxed too.

 

[richardm]

Take a look at spl_taskq_thread_priority. It's a 1 or 0 setting. The documentation is as clear as mud. You can check your current setting with arc_summary| grep -i taskq.

You might also try lowering zio_taskq_batch_pct.

Also, see this thread.