Date: Wed, 22 Jan 2003 17:37:57 -0500 (EST) From: Jeff Roberson <jroberson@chesapeake.net> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Garrett Wollman <wollman@lcs.mit.edu>, <peter@wemm.org>, <arch@FreeBSD.ORG> Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) Message-ID: <20030122173229.D46974-100000@mail.chesapeake.net> In-Reply-To: <200301222144.h0MLifiC009829@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 22 Jan 2003, Matthew Dillon wrote: > 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. I think the argument is for fixing the implementation of shm_open() such that it supports this feature and move it into kernel space. Such that if you use a key preceded by a '/' it will use the filesystem as the namespace and otherwise it will be local and swap backed. Is there something wrong with this approach? > > 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. > A doesn't sound so serious to me, but ok. I think I have an idea of why B happens but can you be more specific? Why does MADV_FREE not work with file backed memory? I'm not arguing against the ability to mmap an object that lives in swap. I'd just like to see if there are improvements that we could make to the vm to handle the mmap file case. Cheers, Jeff 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?20030122173229.D46974-100000>