From owner-freebsd-mips@FreeBSD.ORG Mon Dec 6 09:54:34 2010 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 24B941065670 for ; Mon, 6 Dec 2010 09:54:34 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-gw0-f49.google.com (mail-gw0-f49.google.com [74.125.83.49]) by mx1.freebsd.org (Postfix) with ESMTP id DEC738FC1C for ; Mon, 6 Dec 2010 09:54:33 +0000 (UTC) Received: by mail-gw0-f49.google.com with SMTP id 20so6348909gwj.36 for ; Mon, 06 Dec 2010 01:54:33 -0800 (PST) Received: by 10.150.146.18 with SMTP id t18mr5143550ybd.19.1291629273682; Mon, 06 Dec 2010 01:54:33 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.236.108.51 with HTTP; Mon, 6 Dec 2010 01:54:13 -0800 (PST) In-Reply-To: References: From: Juli Mallett Date: Mon, 6 Dec 2010 01:54:13 -0800 X-Google-Sender-Auth: eEVhoXDBjzuaACPzixiIVoSSArw Message-ID: To: "Jayachandran C." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alan Cox , freebsd-mips@freebsd.org Subject: Re: uma_small_alloc from direct mapped memory. 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: Mon, 06 Dec 2010 09:54:34 -0000 Hi JC, On Sun, Dec 5, 2010 at 22:39, Jayachandran C. wr= ote: > The attached patch uses the mechanism used to allocate page table > pages for UMA small allocations too. =A0This will make sure that all the > small UMA allocations comes from KSEG0 pages in 32 bit and XKPHYS in > 64bit. > > This reduces TLB misses in kernel code significantly, and can give > major performance advantage for applications that spent a lot of time > in kernel. > > Please let me know your comments. It looks reasonable to me. I've gone over the other unmerged changes related to the direct map in my Octeon branch and wonder if you would like to handle other expansions of use of the direct map, particularly on n64: o) Using the direct map for sendfile. (Making sf_buf_alloc and sf_buf_free no-ops, like on sun4v, I think, rather than the whole freelist approach of e.g. sparc64, but I don't remember the details of why one implementation vs. the other at the moment.) o) Making uiomove_fromphys use XKPHYS on n64. (I think that this will help our pipe performance a non-trivial amount, but it has been some time since I tested it.) If not I will try to make those changes in the near future, but I thought that (1) perhaps you had a reason for not making those changes with your n64 work in -CURRENT (2) since you're making related changes, you might like to do so, and also might be able to quantify what you feel the overall affect on performance to be. Thanks again for all of your work in this area! Juli.