Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 1 Oct 2012 21:46:26 +0530
From:      "Jayachandran C." <c.jayachandran@gmail.com>
To:        Alan Cox <alc@rice.edu>
Cc:        mips@freebsd.org
Subject:   Re: optimizing TLB invalidations
Message-ID:  <CA%2B7sy7CdcGzpOG6ou4vE30GSvz%2BwMQ1XAaUGhuGxasC1oQm5Gw@mail.gmail.com>
In-Reply-To: <505DE9D4.5010204@rice.edu>
References:  <505DE9D4.5010204@rice.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Sep 22, 2012 at 10:09 PM, Alan Cox <alc@rice.edu> 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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2B7sy7CdcGzpOG6ou4vE30GSvz%2BwMQ1XAaUGhuGxasC1oQm5Gw>