Comments on UV tlb flushing

[Jeremy Fitzhardinge]

I'm just reworking the x86 tlb code to use smp_call_function_mask, and I 
see how the UV tlb flushing hooks in.  A few things occur to me:

  1. There should be a CONFIG_X86_UV to select this code.  tlb_uv.o is
     around 6k, which is not trivial overhead to subject every x86_64
     kernel to.
  2. CONFIG_X86_UV should either depend on or select CONFIG_PARAVIRT.
  3. You should hook into paravirt_ops to enable your tlb-flush code. 
     That is, in - say - uv_bau_init() you do
     "pv_mmu_ops.flush_tlb_others = uv_flush_tlb_others".  This removes
     a test/branch in the generic code.  Using paravirt_ops may open
     other opportunities to put UV-optimised functions in place without
     having to modify generic code.

My understanding is that the UV hardware has some kind of 
payload-carrying IPI mechanism, which is a capability could be useful to 
express in a higher-level way in the kernel.  Certainly I could imagine 
using it in a virtual environment as a way to do inter-VCPU messaging 
with less context switch overhead.

Thanks,
   J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/