From owner-freebsd-net  Sat Jul 15 12:16:57 2000
Delivered-To: freebsd-net@freebsd.org
Received: from implode.root.com (root.com [209.102.106.178])
	by hub.freebsd.org (Postfix) with ESMTP
	id 6132837B79D; Sat, 15 Jul 2000 12:16:55 -0700 (PDT)
	(envelope-from dg@implode.root.com)
Received: from implode.root.com (localhost [127.0.0.1])
	by implode.root.com (8.8.8/8.8.5) with ESMTP id MAA20589;
	Sat, 15 Jul 2000 12:04:39 -0700 (PDT)
Message-Id: <200007151904.MAA20589@implode.root.com>
To: Alfred Perlstein <bright@wintelcom.net>
Cc: net@freebsd.org, dillon@freebsd.org
Subject: Re: mbuf refcnt and sendfile 
In-reply-to: Your message of "Sat, 15 Jul 2000 06:55:06 PDT."
             <20000715065506.Y25571@fw.wintelcom.net> 
From: David Greenman <dg@root.com>
Reply-To: dg@root.com
Date: Sat, 15 Jul 2000 12:04:39 -0700
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

>http://www.freebsd.org/cgi/query-pr.cgi?pr=19866
>
>David, I'm pretty sure you didn't like the 'fix' for the mbuf
>cluster refcount presented in this PR (linking all copies using
>a doubly linked list), I have presented an alternative:
>
>     Instead of keeping them in a linked list there should be an int/char *
>     in the mbuf header that works the same way mclrefcnt does.  Instead
>     of managing a linked list all one has to do is copy the pointer into
>     the new mbuf header and increment it, and decrease it on free, when
>     it's zero the deref code is called.
>
>I was wondering what your thoughts on this are?

   I thought it seemed very clever.

>I also had an idea to save on sf_buf's in sendfile:
>
>  Forget about them, set the m_ext->ext_buf to point directly at the
>  vm_page_t backing the mbuf, you don't need the extra indirection.
>
>I think that could work if you did a vm_page_wire and pmap_qenter
>for each mbuf ref callback and a vm_page_unwire and pmap_qremove
>for each mbuf free callback.

   This one makes my brain hurt (too much to consider).

   There's only one mapping address, so multiple pmap_qenter's would be a
no-op and the first pmap_qremove would remove the mapping, which is not
what you want. You can't use the wire count == 0 to decide when to remove
the mapping either, since it is used all over the system for other
purposes. Basically, you have to have a seperate counter of sendfile
consumers of the page - I don't see any way around that.

-DG

David Greenman
Co-founder, The FreeBSD Project - http://www.freebsd.org
Manufacturer of high-performance Internet servers - http://www.terasolutions.com
Pave the road of life with opportunities.


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