From owner-freebsd-arch Wed Jan 22 14:49:14 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C73937B401 for ; Wed, 22 Jan 2003 14:49:12 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEF4B43F18 for ; Wed, 22 Jan 2003 14:49:11 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0MMn90i016698; Wed, 22 Jan 2003 14:49:10 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0MMn9e5016697; Wed, 22 Jan 2003 14:49:09 -0800 (PST) Date: Wed, 22 Jan 2003 14:49:09 -0800 (PST) From: Matthew Dillon Message-Id: <200301222249.h0MMn9e5016697@apollo.backplane.com> To: Jeff Roberson Cc: Garrett Wollman , , Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) References: <20030122173229.D46974-100000@mail.chesapeake.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message