Date: Wed, 22 Jan 2003 14:49:09 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Jeff Roberson <jroberson@chesapeake.net> Cc: Garrett Wollman <wollman@lcs.mit.edu>, <peter@wemm.org>, <arch@FreeBSD.ORG> Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) Message-ID: <200301222249.h0MMn9e5016697@apollo.backplane.com> References: <20030122173229.D46974-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
: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?
Moving shm_open() to kernel space? That's a pretty tall order. I
don't think anyone has proposed that until now. shm_open() in its
full glory must manage both namespace private and namespace-filespace
operations.
I would argue that namespace private operations are far better handled
in userspace then kernelspace (why waste kernel memory managing
private namespaces?). I would say that we would almost certainly want
to keep shm_open() in userspace and add a system call (aka getmemfd())
that can eventually be used to support shm_open() behind the scenes.
Additionally, namespace-filespace operations are far better handled with
an fattach()-like system call, and give us a far more general feature-set
then we would get implementing shm_open() in kernel space.
To do that requires a two-stage process of which my current proposed
patch is only stage-1, since we have no current ability to call
ftruncate() on a descriptor, only a vnode. In stage-2 we could revamp
the struct file function vector support to support high-level syscalls
like ftruncate() at a high level, leaving the VFS vector intact to
support those same system calls at a lower level. But that's a lot of
work and not really relevant to the discussion vis-a-vie adding a new
system call (because the work would not impact the new syscall's
prototype, it would simply add new capabilities to the returned
descriptor). I'm not against idea, but I think it would be rather silly
to try to implement the whole mess all at once.
: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
MADV_FREE does not work on vnode-backed VM objects. It never has. It
could probably be made to work ala-solaris (revert to original contents
of file) but this still leaves us with the swap-backing problem.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?200301222249.h0MMn9e5016697>