On 12/20/2010 02:17 PM, Adam Jackson wrote:
On Mon, 2010-12-20 at 13:07 -0800, Fernando Lopez-Lezcano wrote:
I would like to bring to the attention of the list another current usage of the tmpfs mounted on /dev/shm in Fedora packages:
Jack (the Jack Audio Connection Kit, jackaudio.org) has been using the file api (apologies if my wording is not absolutely correct in unix terms) on the tmpfs filesystem that is mounted on /dev/shm for a very long time (10 years?). "/tmp" is not useful to Jack because Jack's internal communication pipes can't be stored in any disk based journaled filesystem as the latencies involved in accessing them cause glitches in the audio streams handled by Jack.
This is right and wrong.
Right! Thanks very much for looking at this in such detail (I presume you looked at the 1.9.6 code base?).
JACK uses /dev/shm for two purposes on Linux [1]. The first is as the definition of what its configure script calls HOST_DEFAULT_TMP_DIR. This path is only used as a name to which to attach the jack sockets. The extent to which this will _ever_ touch the disk, even on a journaled filesystem, is:
- eventually, the inode for that socket and the dnode for the containing
directory will have to be written to the disk, once.
- under memory pressure the vfs may decide to throw away the inode cache
for that socket, which would then have to be re-read from disk for subsequent connecting JACK clients.
In other words, these are setup costs, not maintenance costs. This may cause glitches in a realtime scenario to the extent that clients are created and destroyed, but in general I submit that the cost of exec() of those new clients is going to dwarf the cost of the inode cache miss for the JACK socket. [2]
My experience (caveat: a long time ago, maybe everything has changed internally in both jack and the kernel and that has invalidated my experience cache :-) was that using /tmp would lead to constant - not all the time, but very frequent and not correlated with client connection/disconnection - xruns (glitches in the audio), using /dev/shm would fix that immediately. That was why things were moved over to /dev/shm if I remember correctly.
The other usage of /dev/shm is for actual shared memory segments, but the shm layer in jack uses shm_open() and friends, so the use of /dev/shm is simply glibc's implementation detail.
Thanks, -- Fernando
[1] - I have read the JACK source literally once in my life (ie, just now), and I do not claim to be an expert, but this is all I was able to find.
[2] - Though, should someone feel especially enterprising, it would probably be a worthwhile optimization to tweak the inode cache replacement to prefer dropping regular files to sockets, on the grounds that IPC should not be a disk operation. If it doesn't already; I haven't looked.