Messages in this thread | | | Date | Wed, 22 Aug 2012 08:44:38 +0100 | From | "Jan Beulich" <> | Subject | Re: apparent regressions from TLB range flushing page set |
| |
>>> Alex Shi <alex.shi@intel.com> 08/22/12 5:27 AM >>> >> Second, the UV code doesn't flush the full range at all, it simply >> ignores its 'end' parameter (and hence also the "all" indicator). > >Sure. the following rfc patch try to fix it. untested since no hardware.
Sure - this needs to be looked at by a person knowing UV (and I would have thought a change like the one we're discussing here would also have required an ack from such a person), but ...
>--- a/arch/x86/platform/uv/tlb_uv.c >+++ b/arch/x86/platform/uv/tlb_uv.c >@@ -280,12 +280,12 @@ static void bau_process_message(struct msg_desc *mdp, struct bau_control *bcp, > /* > * This must be a normal message, or retry of a normal message > */ >- if (msg->address == TLB_FLUSH_ALL) { >+ if (msg->end == 0) {
How would "end" end up being 0 here? Don't you rather mean "start and end on the same page"? And even if you do, aren't you then losing the intended optimization?
>+ __flush_tlb_one(msg->start); >+ stat->d_onetlb++; >+ } else { > local_flush_tlb(); > stat->d_alltlb++; >- } else { >- __flush_tlb_one(msg->address); >- stat->d_onetlb++; > } > stat->d_requestee++; > >@@ -1113,7 +1114,8 @@ const struct cpumask *uv_flush_tlb_others(const struct cpumask *cpumask, > > record_send_statistics(stat, locals, hubs, remotes, bau_desc); > >- bau_desc->payload.address = start; >+ bau_desc->payload.start = start; >+ bau_desc->payload.end = end; > bau_desc->payload.sending_cpu = cpu; > /* > * uv_flush_send_and_wait returns 0 if all cpu's were messaged,
Jan
| |