Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Jan 2003 13:44:41 -0800 (PST)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Garrett Wollman <wollman@lcs.mit.edu>
Cc:        peter@wemm.org, arch@FreeBSD.ORG
Subject:   Re: getsysfd() patch #1 (Re: Virtual memory question) 
Message-ID:  <200301222144.h0MLifiC009829@apollo.backplane.com>
References:  <200301220304.h0M34TMB099694@apollo.backplane.com> <200301222052.h0MKqP4N041427@khavrinen.lcs.mit.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
    You guys are talking apples and oranges here.  shm_open() is a libc
    call, not a system call.  getmemfd() or equivalent is a system call
    and performs a function that no other system call can duplicate.  Until
    we fix our VFS layering system to provide a call vector for file
    descriptors, the descriptors returned by the two APIs are not going to
    be compatible.  e.g. you can call ftruncate() on an shm_open() 
    descriptor (because it is essentially just a file descriptor), but you
    cannot call ftruncate() on a getmemfd() descriptor.

    The primary problem with using shm_open() in its current implementation
    is the fact that the anonymous memory associated with the descriptor
    is file-backed when what we really want is swap-backed anonymous memory.
    file-backed memory has serious repercussions that swap backed memory does
    not.  The two most serious repercussions are (A) it will eat space in
    the filesystem and (B) if you do not pre-zero the space, any pageout
    activity will (due to its randomness) create an extremely inefficient,
    highly fragmented file.  Additionally, the most important madvise()
    function, MADV_FREE, does not work on file-backed memory.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


:-----BEGIN PGP SIGNED MESSAGE-----
:Hash: SHA1
:
:In article <20030122041546.393AF2A8A5@canning.wemm.org> you write:
:
:>I'd rather do that than add another arg to the memfd syscall.  Otherwise
:>we're heading into shm_open() look and feel territory.  Hmm.  I wonder if
:>the POSIX folks would object to us calling the syscall shm_openfd() ?
:
:Can you please explain just what precisely your problem is with
:shm_open()?  If we're going to reinvent the wheel, please, let's skip
:the square and hexagonal stages.
:
:- -GAWollman
:
:-----BEGIN PGP SIGNATURE-----
:Version: GnuPG v1.0.7 (FreeBSD)
:
:iD8DBQE+LwSHI+eG6b7tlG4RAj56AKCFhYoHdkXhvIX1sGPX9PgXB2dttwCgiR75
:53DaDGocAf2aI5F7xR09398=
:=sswO
:-----END PGP SIGNATURE-----
:

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200301222144.h0MLifiC009829>