From owner-freebsd-mips@FreeBSD.ORG Mon Oct 1 16:16:36 2012 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60773106564A for ; Mon, 1 Oct 2012 16:16:36 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id E27FC8FC15 for ; Mon, 1 Oct 2012 16:16:35 +0000 (UTC) Received: by wibhr7 with SMTP id hr7so2211616wib.13 for ; Mon, 01 Oct 2012 09:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=skDOJA81lKsNvhR4MjQIFAnnYPSDhhkUD2XkFmE4m8A=; b=f85d3qE45cbqh3ifvA7cNI5IjvZnlhBQIO2xySod1bvk0Eqx5NqeLYhfY0jyQZLGqQ SKcfoztYq5fpkm+dB4FOFZJ/3TfcvqjBI/326StTBrHQZQpgCx7o9J+jbeS19MPKUDtR mLBgpfvXsbWLFmUwofnoqGbKFUzSHy8oVrFFa1NQrZEw3nmRgG3AnahgiuqcGgMqpFf/ q7lpXtIGco8bwZbRyglfshcuM1auTkSAnR92B6MW8+j/Y5Yuug6UEZ4+ZpOVJVgT+VqS OUI0orV3sJQEWdFzCA0fJqSiR7Kzp4l9FsMVVago3i2K1jZet4i/p+X7eY5rK6Vqdt+V hHYg== MIME-Version: 1.0 Received: by 10.180.79.34 with SMTP id g2mr10441088wix.19.1349108186737; Mon, 01 Oct 2012 09:16:26 -0700 (PDT) Received: by 10.216.138.224 with HTTP; Mon, 1 Oct 2012 09:16:26 -0700 (PDT) In-Reply-To: <505DE9D4.5010204@rice.edu> References: <505DE9D4.5010204@rice.edu> Date: Mon, 1 Oct 2012 21:46:26 +0530 Message-ID: From: "Jayachandran C." To: Alan Cox Content-Type: text/plain; charset=ISO-8859-1 Cc: mips@freebsd.org Subject: Re: optimizing TLB invalidations 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, 01 Oct 2012 16:16:36 -0000 On Sat, Sep 22, 2012 at 10:09 PM, Alan Cox wrote: > Can you please test the attached patch? It introduces a new TLB > invalidation function for efficiently invalidating address ranges and uses > this function in pmap_remove(). > > Basically, the function looks at the size of the address range in order to > decide how best to perform the invalidation. If the range is small compared > to the TLB size, it probes the TLB for pages in the range. That said, the > function understands that pages come in pairs, and so it won't probe for odd > page numbers. In contrast, the current code in pmap_remove() will probe for > both the even and odd page. On the other hand, if the range is large, then > the function changes its approach. It iterates over the TLB entries > checking each to see if it falls within the range. This can eliminate an > enormous number of TLB probes when a large virtual address range is > unmapped. Finally, on a multiprocessor, this change will reduce the number > of IPIs to invalidate TLB entries. There will be one IPI per range rather > than one per page. > > Ultimately, this new function could be applied elsewhere, like > pmap_protect(), but that's a patch for another day. Tested this on my XLP 64 bit SMP config, and did not any issues. The compilation test did not show much change in performance, but I think I need to run a multi-threaded benchmark to see the performance improvement. JC.