POSIX Shared memory support

[Rob Landley]

On Monday 30 July 2007 2:11:18 am Carlo Zinato wrote:
> Arnar Mar Sigurðsson ha scritto:
> > Is there any work being done to bring POSIX shared memory support to
> > uclibc? (shm_open and shm_unlink)
>
> Hi Arnar,
>
> You may read this thread:
>
> http://www.uclibc.org/lists/uclibc/2006-December/017027.html
>
> I had the same problem, and I successfully use /tmp (ram filesystem) to
> exchange blocks of data between processes.

I'm still a bit behind from my move, but I point out that User Mode Linux used 
to use /tmp and assume it had tmpfs mounted on it, and that this is NOT 
necessarily the case, and no spec requires it.  If it doesn't have tmpfs 
mounted on it (PLD linux, case in point) then dirtying lots of pages in there 
means you're constantly writing to disk which is the nastiest thing you can 
do to the block layer and kills system performance in a big way.

However, /dev/shm is where the LSB FHS demands an instance of tmpfs.  A system 
that doesn't have a tmpfs mounted there probably won't have that directory, 
so it's a darn easy error to detect.

(Yes, modern shared memory is just an mmap of a file in a tmpfs mount, and any 
other semantics layered on top of that are implemented that way deep down.  
Way back when, before tmpfs was invented, you'd open a file, mmap it, and 
then delete it, and the page cache knew to stop flushing pages to disk for an 
inode with a filesystem refcount of zero because it would go away when 
closed.  Still allocated blocks out of the filesystem and thus took up space 
on disk, of course, but it worked.  Alas, Linux took out  the check for a 
deleted inode in the page cache flush when tmpfs went in, so pulling that 
trick on /tmp can drive your system into disk thrashing if it isn't tmpfs.)

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.