On Tue, Dec 21, 2010 at 2:26 AM, Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx> wrote: > 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. Well /tmp should be mounted tmpfs anyway (I have been doing this for years and it is working just fine). tmp isn't a persistent storage so it makes a lot of sense, and it is *not* a dumping ground for giant files (apps that try to do that are just broken). -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
