Page 2 of 3

Re: shm tmps

Posted: Mon Jun 04, 2018 8:30 pm
by khz
Jack Winter wrote:But, JACK has supported /dev/shm for years, and distros too, would be weird for a system today to be missing it.
I thought so too.
Searched for information (see links)
Tried and succeeded.
I was wondering why this is so badly documented.
shm RAM[X] Yes ;-)
There are options you can choose if you need it/... Freedom: everyone decides for himself because hardware/software combinations can be complex.

Re: shm tmps

Posted: Mon Jun 04, 2018 9:32 pm
by khz
protozone wrote:I'm running a 32-bit distro, and not in PAE mode, so I can't get to the other 4 GB of RAM anyhow, right?
32-bit system maximal 4 GB. Yes.
With the shm entry all audio processes run in RAM.
Possibly because of the 32-bit system?

Posted: Tue Jun 05, 2018 12:51 am
by protozone
I only started coming here a few weeks ago, and the /dev/shm assignment thingie is new to me. I've only been using Linux for audio for a few years now. I think I did read that messing with it or tmpfs isn't needed anymore from a decent configuration wiki, probably linuxaudio.org (?) I forget what it's called; for me, it's the main one even though yeah, it's out of date.

I did take out the fstab entry. I'm used to editing the fstab to put in the noatime and checking the UUID/BLKID's. But anyhow, I took out the fstab entry and the error message in dmesg > info.txt is fine now.

I deleted the grub "quiet splash" entry so I can watch during bootup what the errors and statuses are.
Anyways, I do agree optimizations are somewhat optimal. And so are xruns :D :lol:

Seriously, though, thanks very much it's all helpful.
I think maybe the differences I've had are because I used to only run Xubuntu/Lubuntu/Ubuntu Studio, but I recently switched to Debian & AVLINUX.

I do think that it's a good idea to disable last file access logging (noatime in fstab). That's a very good idea for reducing I/O overhead. I have no idea why that "feature" is even needed? We already have modification dates and creation dates, and to a minor degree, delete dates via logs and and trashcan and stuff.

I do find that there are a few other decent optimizations that are more than optional, but they tend to be within the actual DAW programs.

Re: shm tmps

Posted: Tue Jun 05, 2018 7:35 am
by khz
@All
If the documentation there (wiki.linuxaudio.org) is incorrect we should update it. Many contributions were created by us there (LM <> Wiki). If something changes we should also adapt the wiki. Anything else would be illogical as it would lead to confusion due to possible (outdated) misinformation.

The Wiki entries should be current and ~easily verifiable/traceable.

Shm/tmps should be clearly formulated or, if no longer needed, removed.
Also the realTimeConfigQuickScan script should be adjusted if necessary.
The "increase max_user_watches by adding 'fs.inotify.max_user_watches = 524288'" I find confusing. http://wiki.linuxaudio.org/wiki/system_ ... sysctlconf. For a newcomer, perhaps even more confusing.

####

@shm/tmps
I hadn't found much information about shm/tmps. Not only on the wiki, but in the whole internet I have read very little about it.

It doesn't seem logical to me that shm is obsolete. When jackdbus work processes are running in RAM, this still makes a very big ~gain in performance today!

Is there any further technical information/documentation?

Re: shm tmps

Posted: Wed Jun 06, 2018 11:59 am
by Jack Winter
I'll try again. Forget about /tmp (tmpfs) when it comes to JACK. AFAIK All/most kernels in use today support /dev/shm and that is what JACK will use if it's available. The exception might be some really ancient or turnkey system (or home built kernel), there it would probably be of advantage to mount /tmp as a tmpfs unless already so.

Re: shm tmps

Posted: Wed Jun 06, 2018 7:47 pm
by khz
Jack Winter wrote:I'll try again. Forget about /tmp (tmpfs) when it comes to JACK.
Yes. But ( ;-) )
realTimeConfigQuickScan:

Code: Select all

** Warning: no tmpfs partition mounted on /tmp
The realTimeConfigQuickScan script tells me I need this. Or do I misunderstand the message from the realTimeConfigQuickScan script?
Tmps is still useful when you compile a lot (for example Gentoo). But it has nothing to do with audio and therefore the message irritates me.
It is also written in the wiki: https://wiki.linuxaudio.org/wiki/system ... ilesystems
Both Jack1 and Jack2 now use /dev/shm/ so mounting /tmp/ to tmpfs is not necessary anymore.
Jack Winter wrote:AFAIK All/most kernels in use today support /dev/shm and that is what JACK will use if it's available.
Is JACK also used shm when "mount | grep shm" nothing is output? So no shm is mounted?
Then why do I get the error message from qjackctl?
qjackctl:

Code: Select all

 cannot create /dev/shm/jack-1000 directory (Permission denied)
What was the reason for the problem of protozone?

I have this on my console:

Code: Select all

 ~ $ mount | grep shm
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime)
Neither qjackctl nor realTimeConfigQuickScan has this message.
Without shm I get the error from qjackctl, without the tmps the error from realTimeConfigQuickScan. :roll:

Re: shm tmps

Posted: Thu Jun 07, 2018 9:18 pm
by protozone
I was getting some strange protection errors when trying to use certain programs on the desktop and in the terminal and it was also showing up during boot. So I took out the fstab entry, and the problems went away. I forget what the errors were. I will perhaps try it again. Because if audio processes run in RAM, then that would be good probably. However, I think the settings for mounting protections might be wrong for certain distros. I don't know much about it. Or maybe the defaults vary.

I'm not motivated to change anything right now because my system is currently stable and I'm making tunes. But I'll go back and look at it again.

As far as that other wiki goes, the section about gvfs stuff is outdated. The services don't have those names anymore. They were subtely changed a few years ago in both Ubuntu and Debian.

Here's an example of what they actually look like in my bash script to disable them:

Code: Select all

#!/bin/sh
sudo mv "/usr/share/dbus-1/services/org.gtk.vfs.Daemon.service" "/usr/share/dbus-1/services/org.gtk.vfs.Daemon.service.disabled"
sudo mv "/usr/share/dbus-1/services/org.gtk.vfs.Metadata.service" "/usr/share/dbus-1/services/org.gtk.vfs.Metadata.service.disabled"

Re: shm tmps

Posted: Fri Jun 08, 2018 7:03 am
by khz
If your system runs well, leave it like this.

I don't know much about shm, what I found on the internet, I posted .. .

If audio processes run in RAM it should still be interesting in 2018, but I may be wrong.

Yes GNU/Linux is developing and therefore an adaptation of WIKI would make sense, I expect the same from my distribution.
Or we have to reckon with more outdated and/or incorrect information. But then you can trust less and less information about GNU/Linux on the Internet, which would be illogical.

Re: shm tmps

Posted: Fri Jun 08, 2018 8:14 pm
by lilith
I have this:

Code: Select all

tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,noexec)

Code: Select all

shm     /dev/shm        tmpfs   nodev,nosuid,noexec         0       0
tmpfs   /tmp            tmpfs   defaults,size=7500M,mode=1777   0   0

Code: Select all

Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
udev            3,7G       0  3,7G    0% /dev
tmpfs           743M    1,3M  742M    1% /run
/dev/sda1        28G     11G   16G   43% /
tmpfs           3,7G    236M  3,4G    7% /dev/shm
tmpfs           5,0M    4,0K  5,0M    1% /run/lock
tmpfs           3,7G       0  3,7G    0% /sys/fs/cgroup
tmpfs           7,4G    8,0K  7,4G    1% /tmp
/dev/sda6       194G     22G  162G   12% /home
tmpfs           743M     20K  743M    1% /run/user/1000
I don't have problems with it. Can it be that it's better for SSDs? As data is written into RAM instead to the SSD it reduces write / read cycles to the SSD.

https://superuser.com/questions/45342/w ... -i-use-tmp
https://www.cyberciti.biz/tips/what-is- ... usage.html

Re: shm tmps

Posted: Sat Jun 16, 2018 1:41 pm
by khz
lilith wrote:Can it be that it's better for SSDs? As data is written into RAM instead to the SSD it reduces write / read cycles to the SSD.
A pleasant accompanying effect. IMHO :-D
lilith wrote:

Code: Select all

shm     /dev/shm        tmpfs   nodev,nosuid,noexec         0       0
tmpfs   /tmp            tmpfs   defaults,size=7500M,mode=1777   0   0
"size=7500M" <-- adjusted to your actually built-in RAM, size=lessM than actually built-in RAM. (M = Megabyte) <-- You heeded that?

Re: shm tmps

Posted: Sat Jun 16, 2018 2:08 pm
by lilith
@khz: I don't understand your last question. I have 8GB RAM and 7.5 GB is less.

Re: shm tmps

Posted: Sat Jun 16, 2018 2:21 pm
by khz
All right. That was my question. You did (less than actually built-in RAM).
That you adjust the value to your built-in RAM

Re: shm tmps

Posted: Sat Jun 16, 2018 2:55 pm
by Jack Winter
I must admit that this whole thread confuses me. I've tried to read the entire thread a couple of times :)

This is what I know.

It's probably a very good idea to keep your /tmp mounted as a tmpfs (ramdisk). It's a filesystem meant for temporary files, and it typically doesn't get big, on my system right now after a weeks uptime 304MB. On my system it's taken care of the distro (archlinux), I have no /etc/fstab entry for it. The mount command shows this: tmpfs on /tmp type tmpfs (rw,nosuid,nodev)

JACK prefers to use /dev/shm, as it's very fast for I/O. Again I have no fstab entry for it as it's taken care of my distro. mount shows: tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev). With JACK and REAPER running it's using 65MB, though a lot of those are leftover files after killing LinVst that also uses it.

IIRC, a tmpf defaults to half available ram, so you can use the size option if you want to make that bigger or smaller.

I think if you use gentoo, then you have to either use some overlay that makes sure this is all done, or you have to make sure to do it yourself :)

Regarding the realTimeConfigQuickScan script. I get the following "not good". I'll comment after each one:

Code: Select all

Checking CPU Governors... CPU 0: 'powersave' CPU 1: 'powersave' CPU 2: 'powersave' CPU 3: 'powersave' CPU 4: 'powersave' CPU 5: 'powersave' CPU 6: 'powersave' CPU 7: 'powersave'  - not good
Set CPU Governors to 'performance' with 'cpufreq-set -c <cpunr> -g performance'
See also: http://linuxmusicians.com/viewtopic.php?f=27&t=844
I use the Intel pstate driver. AFAIK you can't change governor on it. What you can do on most systems is to write 0 as a dword into /dev/cpu_dma_latency and keep the handle open. On my i7-2600k it doesn't seem to make a difference, on my i7-4700HQ quite a lot. This effectively makes the CPUs stay in C0/C1 states.

Code: Select all

Checking swappiness... 60 - not good
** vm.swappiness is larger than 10
set it with '/sbin/sysctl -w vm.swappiness=10'
See also: http://linuxmusicians.com/viewtopic.php?f=27&t=452&start=30#p8916
I've played with swappiness and never found it useful. I still run into occasional "swap storms" when I don't pay attention. The best for me is to kill the browsers every few days to regain ram :)

Code: Select all

Checking checking sysctl inotify max_user_watches... < 524288 - not good
increase max_user_watches by adding 'fs.inotify.max_user_watches = 524288' to /etc/sysctl.conf and rebooting
For more information, see http://wiki.linuxaudio.org/wiki/system_configuration#sysctlconf
Here I have 8192, should I increase this?

Code: Select all

Checking access to the high precision event timer... not readable - not good
/dev/hpet found, but not readable.
make /dev/hpet readable by the 'audio' group
For more information, see http://wiki.linuxaudio.org/wiki/system_configuration#hardware_timers
Checking access to the real-time clock... not readable - not good
/dev/rtc found, but not readable.
make /dev/rtc readable by the 'audio' group
For more information, see http://wiki.linuxaudio.org/wiki/system_configuration#hardware_timers
Regarding the rtc clock it's most likely not used at all nowadays. cat /proc/interrupts | grep rtc showsthat it's fired exactly once on my system since boot. hpet probably also doesn't have to be accessible by the user as AFAIK JACK uses hrtimers built into the kernel.

Code: Select all

Checking whether you're in the 'audio' group... no - not good
add yourself to the audio group with 'adduser $USER audio'
I don't use an "audio" group at all. The one group I've added to my system is "realtime", and I hope this becomes standard on Archlinux some day. The people behind systemd/policykit/archlinux would prefer that the audio group isn't used to give access to devices, as that breaks how they conceive of multi seat computers.

I think it would be exceedingly hard to make a script like realTimeConfigQuickScan perfect. Maybe best to take it as suggestions and not as the gospel truth.

Re: shm tmps

Posted: Sat Jun 16, 2018 3:17 pm
by khz
Jack Winter wrote:I think it would be exceedingly hard to make a script like realTimeConfigQuickScan perfect. Maybe best to take it as suggestions and not as the gospel truth.
Full approval.
khz wrote:(I think one of many good possibilities of all this is that everyone is individual, depending on LAW focus(s), ... and hardware, the combinations of optimizations, distribution desktop selection,... relatively easy to implement.
Since there are - advantages and disadvantages at the same time - relatively many possible combinations, this can be tested out....:pcsuxx: ....
How well all the optimizations are coordinated with each other (or not)... .

Test individually and take what works best for you. Everything - amongst other things 100 % RT - does not have to be better.)

Re: shm tmps

Posted: Mon Jun 18, 2018 7:08 am
by khz
protozone wrote:I'm running a 32-bit distro
I suspect that this is due to either the 32-bit system or to the unadapted size=RAM.
("size=7500M" <-- adjusted to your actually built-in RAM, size=lessM than actually built-in RAM. (M = Megabyte) <-- You heeded that?)
khz wrote:Tmps is still useful when you compile a lot (for example Gentoo). But it has nothing to do with audio and therefore the message irritates me.
So if you don't compile much, you can leave the "tmpfs /tmp tmpfs defaults,size=7500M,mode=1777 0 0" entry outside.
protozone wrote:Luckily the system still boots.
What did you do to get it to boot again?
Booted a live distribution and mounted your system partition on the hard disk, in which "7etc/fstab" took out the 2 entries?
protozone wrote:The goal is to give everyone on the internet my full list of techniques I used to go from Windows crashing on a used computer to installing a Linux distro to making it a DAW to deleting Windows to optimizing the Linux DAW.
Great && Thanks!