From owner-freebsd-mips@FreeBSD.ORG Tue Jan 25 17:48:40 2011 Return-Path: Delivered-To: freebsd-mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 373ED1065672 for ; Tue, 25 Jan 2011 17:48:40 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id D9E558FC1D for ; Tue, 25 Jan 2011 17:48:39 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id p0PHef3c042928 for ; Tue, 25 Jan 2011 10:40:41 -0700 (MST) (envelope-from imp@bsdimp.com) Message-ID: <4D3F0B19.4060907@bsdimp.com> Date: Tue, 25 Jan 2011 10:40:41 -0700 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101211 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-mips@FreeBSD.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: [PATCH] update sf_buf and uio for n64 X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 17:48:40 -0000 On 01/25/2011 06:48, Jayachandran C. wrote: > This is one of the remaining pieces in n64 work from Juli's octeon > branch. The attached patch updates the sf_buf code and uio_machdep.c > in n64 compilation to use direct mapping. > > Planning to check this in later this week, if there are no objections. > > JC. > > > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" I really like the uio_machdep.c. I think it is good and can go in without further objection. I like the idea of the n64 direct mapping of the sbufs. That's a good optimization. I get nervous when I see some code implemented in one place on one ifdef branch, and in a completely different file for another. Is the gain in efficiency sufficient to justify this odd split? If not, then having all the code in vm_machdep.c might make more sense. If the gain is enough, then having a comment in vm_machdep.c pointing to sf_buf.h would be good to have as well... (that's assuming the simplifications suggested by Andrew Duane don't change the code distribution). Warner