Tmpfs on /dev/shm
 

I know that /dev/shm should have tmpfs mounted on it to enable POSIX shared memory.

But my /dev/ already has a tmpfs mounted on it (which is fairly common these days, for udev.)

Is it necessary to mount a separate tmpfs on /dev/shm, or will POSIX shared memory work fine with a subdirectory of a tmpfs?

/dev/shm is the shared memory implementation in recent kernels. Mounting tmpfs on /dev/shm places it into the kernel shared memory implementation. You should have an entry in /etc/fstab that says:

Older implementations that do not do this are legacy - they will go away as they are updated by the distribution.

Yes, I am aware of all that, and I am currently mounting tmpfs on /dev/shm.

My question is this: If I already have tmpfs mounted on /dev, will that allow POSIX shared memory to work (since /dev/shm will be on a tmpfs?) Or does it need an entire filesystem under /dev/shm?

Yes, POSIX shared memory works either way.

Thanks!
I'll prune my fstab a little ;-)

Why do you care ???.
You won't be "saving" anything.

I will be saving space in my fstab, and simplifying the mount-dance in the bootscripts (/dev/shm is a particularly mean case because its mount point doesn't exist when /dev comes into existence, since /dev is another tmpfs and thus blank; so it stops mount -a -t tmpfs from working, when it would otherwise. Putting individual mount commands in the bootscripts is bad both because it's ugly, and because you have to edit your bootscripts whenever you change your system arrangement.)

I can also reduce the system to two tmpfs's (/dev and /tmp); since my package manager compiles packages in /tmp, and kde caches e.g. web pages there, I have the /tmp max size set to 5G, the same as my swap. This means that when running ram-intensive applications, the tmpfs can be pushed entirely to disk and all the ram made available, but otherwise it will live in unused memory and be really fast. Having two other tmpfs's (which by default set a maximum size of half of physical RAM) means that it is theoretically possible to entirely fill RAM by writing enough to those three filesystems, thus disabling the system; which can be gotten around by setting maxsizes on those, but that's unnecessary complication and restriction if one of them isn't needed.