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.