On Thu, Nov 22, 2001 at 10:43:48PM +1100, Paul Mackerras wrote:
> The patch below changes access_one_page in kernel/ptrace.c to use a
> new function, flush_icache_user_range, instead of flush_icache_page as
> at present. The reason for making this change is that
> flush_icache_page is also called in do_no_page and do_swap_page, where
> it does a fundamentally different job. Decoupling the two makes it
> possible to improve performance, because we can make flush_icache_page
> do the flush only when needed.
>
> This patch particularly affects alpha: for alpha I renamed the
> existing flush_icache_page to flush_icache_user_range and made
> flush_icache_page a no-op. This is based on a suggestion from
> Andrea and the comments in the code. I would be very interested to
> hear how it affects alpha as regards stability and performance.
>
> For PPC, I have added a flush_icache_user_range that only flushes the
> cachelines that have been modified. I have a more extensive
> cache-flush avoidance patch in the works that depends on this one and
> also needs modifications to clear_user_page and copy_user_page. This
> all gives us a substantial performance increase on PPC.
>
> For all the other architectures I have made flush_icache_user_range
> the same as flush_icache_page, i.e. a no-op for most architectures.
> So this patch should have zero impact except on alpha and PPC, and on
> alpha it should improve performance.
>
> Note that flush_icache_user_range is different from flush_icache_page
> now in that flush_icache_user_range is only called when the page has
> been modified, so we know we do have to flush (if the icache doesn't
> snoop stores by the cpu). In contrast, flush_icache_page is called in
> situations where the page often (usually?) is unmodified, so it makes
> sense to try to work out whether the flush is actually needed.
>
> Comments? Linus, would you be willing to apply this?
I will try to give it a spin, it should be a very nice speedup for
alpha, we were wasting an huge amount of asn (and possibly of IPI too
with threads) during major faults and this will optimize it away.
thanks,
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Nov 23 2001 - 21:00:31 EST