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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
