lkml.org 
[lkml]   [2008]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectComments on UV tlb flushing
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


\
 
 \ /
  Last update: 2008-07-29 02:31    [W:0.085 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site