From owner-cvs-all@FreeBSD.ORG Thu Jun 17 23:22:19 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B674016A4CE; Thu, 17 Jun 2004 23:22:19 +0000 (GMT) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85C1D43D1D; Thu, 17 Jun 2004 23:22:19 +0000 (GMT) (envelope-from alc@cs.rice.edu) Received: from localhost (calypso.cs.rice.edu [128.42.1.127]) by cs.rice.edu (Postfix) with ESMTP id AE4BF4A9C0; Thu, 17 Jun 2004 18:22:17 -0500 (CDT) Received: from cs.rice.edu ([128.42.1.30]) by localhost (calypso.cs.rice.edu [128.42.1.127]) (amavisd-new, port 10024) with LMTP id 23097-01-89; Thu, 17 Jun 2004 18:22:17 -0500 (CDT) Received: by cs.rice.edu (Postfix, from userid 19572) id 576354A9BC; Thu, 17 Jun 2004 18:22:17 -0500 (CDT) Date: Thu, 17 Jun 2004 18:22:17 -0500 From: Alan Cox To: Mike Silbersack Message-ID: <20040617232217.GC18591@cs.rice.edu> References: <200406170008.i5H08NDt085108@repoman.freebsd.org> <20040617173854.GJ61448@elvis.mu.org> <20040617182031.GA8170@samodelkin.net> <20040617184518.GB831@electra.cse.Buffalo.EDU> <20040617204813.GA10670@samodelkin.net> <20040617214827.GB6029@electra.cse.Buffalo.EDU> <7071.208.178.23.220.1087509793.squirrel@208.178.23.220> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7071.208.178.23.220.1087509793.squirrel@208.178.23.220> User-Agent: Mutt/1.4.2i X-Virus-Scanned: by amavis-20030616-p7 at cs.rice.edu cc: src-committers@freebsd.org cc: Max Khon cc: Alfred Perlstein cc: cvs-all@freebsd.org cc: cvs-src@freebsd.org cc: Ken Smith cc: Max Khon Subject: Re: cvs commit: src/sys/sys mbuf.h src/sys/kern uipc_mbuf.c uipc_syscalls.c src/usr.bin/netstat mbuf.c src/lib/libc/sys sendfile.2 X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2004 23:22:19 -0000 On Thu, Jun 17, 2004 at 06:03:13PM -0400, Mike Silbersack wrote: > > On Fri, Jun 18, 2004 at 03:48:13AM +0700, Max Khon wrote: > > > > This particular change is a case of nit-picking. It's small, hard to > > imagine how it could effect someone, etc. But even Bosko said more > > caution 'next time' would be good, I'm just emphasizing why. To some > > extent the output of programs has been an API ever since pipes were > > invented. And unless I'm severely mistaken one of the things we have > > tried to avoid is changing API's once a branch goes -STABLE. > > > > -- > > Ken Smith > > Yes, you hit it right on the head, this IS a case of nitpicking. > > sfbufs are used almost exclusively in conjunction with mbufs, and users > who are interested in mbuf usage will certainly be interested in sfbuf > usage. This is why I displayed the information along with mbuf > statistics, and why I see no reason to add yet another switch to netstat > (or would it be sfstat?) This is true of RELENG_4. In HEAD sf_bufs are very different. They are used to implement pipes, swap-backed mds, exec_map_first_page(), and the vnode pager. In other words, many places where the kernel would create a single-page ephemeral mapping. The sf_buf API has been refactored to facilitate architecture-specific optimizations. For example, on architectures with a direct virtual-to-physical mapping. An sf_buf is nothing more than a cast. In contrast, on i386, we maintain a reference-counted, LRU-managed cache of virtual-to-physical mappings, eliminating many (expensive) TLB invalidations and interprocessor shootdowns. (This also benefits sendfile(2) because concurrent sends of the same file share the same reference-counted sf_bufs, rather than each allocating their own private sf_bufs for mapping the same page(s).) In Dragonfly, I believe is starting to use sf_bufs to reimplement the buffer cache. Regards, Alan