Date: Thu, 17 Jun 2004 18:22:17 -0500 From: Alan Cox <alc@cs.rice.edu> To: Mike Silbersack <silby@silby.com> Cc: Max Khon <fjoe@samodelkin.net> 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 Message-ID: <20040617232217.GC18591@cs.rice.edu> In-Reply-To: <7071.208.178.23.220.1087509793.squirrel@208.178.23.220> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040617232217.GC18591>