1. 12 11月, 2013 1 次提交
    • I
      Revert "x86/UV: Add uvtrace support" · b5dfcb09
      Ingo Molnar 提交于
      This reverts commit 8eba1842.
      
      uv_trace() is not used by anything, nor is uv_trace_nmi_func, nor
      uv_trace_func.
      
      That's not how we do instrumentation code in the kernel: we add
      tracepoints, printk()s, etc. so that everyone not just those with
      magic kernel modules can debug a system.
      
      So remove this unused (and misguied) piece of code.
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      Cc: Mike Travis <travis@sgi.com>
      Cc: Dimitri Sivanich <sivanich@sgi.com>
      Cc: Hedi Berriche <hedi@sgi.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Link: http://lkml.kernel.org/n/tip-tumfBffmr4jmnt8Gyxanoblg@git.kernel.org
      b5dfcb09
  2. 24 9月, 2013 3 次提交
    • M
      x86/UV: Add uvtrace support · 8eba1842
      Mike Travis 提交于
      This patch adds support for the uvtrace module by providing a
      skeleton call to the registered trace function.  It also
      provides another separate 'NMI' tracer that is triggered by the
      system wide 'power nmi' command.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Reviewed-by: NDimitri Sivanich <sivanich@sgi.com>
      Reviewed-by: NHedi Berriche <hedi@sgi.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Link: http://lkml.kernel.org/r/20130923212501.185052551@asylum.americas.sgi.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      8eba1842
    • M
      x86/UV: Update UV support for external NMI signals · 0d12ef0c
      Mike Travis 提交于
      The current UV NMI handler has not been updated for the changes
      in the system NMI handler and the perf operations.  The UV NMI
      handler reads an MMR in the UV Hub to check to see if the NMI
      event was caused by the external 'system NMI' that the operator
      can initiate on the System Mgmt Controller.
      
      The problem arises when the perf tools are running, causing
      millions of perf events per second on very large CPU count
      systems.  Previously this was okay because the perf NMI handler
      ran at a higher priority on the NMI call chain and if the NMI
      was a perf event, it would stop calling other NMI handlers
      remaining on the NMI call chain.
      
      Now the system NMI handler calls all the handlers on the NMI
      call chain including the UV NMI handler.  This causes the UV NMI
      handler to read the MMRs at the same millions per second rate.
      This can lead to significant performance loss and possible
      system failures.  It also can cause thousands of 'Dazed and
      Confused' messages being sent to the system console.  This
      effectively makes perf tools unusable on UV systems.
      
      To avoid this excessive overhead when perf tools are running,
      this code has been optimized to minimize reading of the MMRs as
      much as possible, by moving to the NMI_UNKNOWN notifier chain.
      This chain is called only when all the users on the standard
      NMI_LOCAL call chain have been called and none of them have
      claimed this NMI.
      
      There is an exception where the NMI_LOCAL notifier chain is
      used.  When the perf tools are in use, it's possible that the UV
      NMI was captured by some other NMI handler and then either
      ignored or mistakenly processed as a perf event.  We set a
      per_cpu ('ping') flag for those CPUs that ignored the initial
      NMI, and then send them an IPI NMI signal.  The NMI_LOCAL
      handler on each cpu does not need to read the MMR, but instead
      checks the in memory flag indicating it was pinged.  There are
      two module variables, 'ping_count' indicating how many requested
      NMI events occurred, and 'ping_misses' indicating how many stray
      NMI events.  These most likely are perf events so it shows the
      overhead of the perf NMI interrupts and how many MMR reads were avoided.
      
      This patch also minimizes the reads of the MMRs by having the
      first cpu entering the NMI handler on each node set a per HUB
      in-memory atomic value.  (Having a per HUB value avoids sending
      lock traffic over NumaLink.)  Both types of UV NMIs from the SMI
      layer are supported.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Reviewed-by: NDimitri Sivanich <sivanich@sgi.com>
      Reviewed-by: NHedi Berriche <hedi@sgi.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Link: http://lkml.kernel.org/r/20130923212500.353547733@asylum.americas.sgi.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      0d12ef0c
    • M
      x86/UV: Move NMI support · 1e019421
      Mike Travis 提交于
      This patch moves the UV NMI support from the x2apic file to a
      new separate uv_nmi.c file in preparation for the next sequence
      of patches. It prevents upcoming bloat of the x2apic file, and
      has the added benefit of putting the upcoming /sys/module
      parameters under the name 'uv_nmi' instead of 'x2apic_uv_x',
      which was obscure.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Reviewed-by: NDimitri Sivanich <sivanich@sgi.com>
      Reviewed-by: NHedi Berriche <hedi@sgi.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Link: http://lkml.kernel.org/r/20130923212500.183295611@asylum.americas.sgi.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      1e019421
  3. 21 6月, 2013 1 次提交
    • S
      x86, trace: Add irq vector tracepoints · cf910e83
      Seiji Aguchi 提交于
      [Purpose of this patch]
      
      As Vaibhav explained in the thread below, tracepoints for irq vectors
      are useful.
      
      http://www.spinics.net/lists/mm-commits/msg85707.html
      
      <snip>
      The current interrupt traces from irq_handler_entry and irq_handler_exit
      provide when an interrupt is handled.  They provide good data about when
      the system has switched to kernel space and how it affects the currently
      running processes.
      
      There are some IRQ vectors which trigger the system into kernel space,
      which are not handled in generic IRQ handlers.  Tracing such events gives
      us the information about IRQ interaction with other system events.
      
      The trace also tells where the system is spending its time.  We want to
      know which cores are handling interrupts and how they are affecting other
      processes in the system.  Also, the trace provides information about when
      the cores are idle and which interrupts are changing that state.
      <snip>
      
      On the other hand, my usecase is tracing just local timer event and
      getting a value of instruction pointer.
      
      I suggested to add an argument local timer event to get instruction pointer before.
      But there is another way to get it with external module like systemtap.
      So, I don't need to add any argument to irq vector tracepoints now.
      
      [Patch Description]
      
      Vaibhav's patch shared a trace point ,irq_vector_entry/irq_vector_exit, in all events.
      But there is an above use case to trace specific irq_vector rather than tracing all events.
      In this case, we are concerned about overhead due to unwanted events.
      
      So, add following tracepoints instead of introducing irq_vector_entry/exit.
      so that we can enable them independently.
         - local_timer_vector
         - reschedule_vector
         - call_function_vector
         - call_function_single_vector
         - irq_work_entry_vector
         - error_apic_vector
         - thermal_apic_vector
         - threshold_apic_vector
         - spurious_apic_vector
         - x86_platform_ipi_vector
      
      Also, introduce a logic switching IDT at enabling/disabling time so that a time penalty
      makes a zero when tracepoints are disabled. Detailed explanations are as follows.
       - Create trace irq handlers with entering_irq()/exiting_irq().
       - Create a new IDT, trace_idt_table, at boot time by adding a logic to
         _set_gate(). It is just a copy of original idt table.
       - Register the new handlers for tracpoints to the new IDT by introducing
         macros to alloc_intr_gate() called at registering time of irq_vector handlers.
       - Add checking, whether irq vector tracing is on/off, into load_current_idt().
         This has to be done below debug checking for these reasons.
         - Switching to debug IDT may be kicked while tracing is enabled.
         - On the other hands, switching to trace IDT is kicked only when debugging
           is disabled.
      
      In addition, the new IDT is created only when CONFIG_TRACING is enabled to avoid being
      used for other purposes.
      Signed-off-by: NSeiji Aguchi <seiji.aguchi@hds.com>
      Link: http://lkml.kernel.org/r/51C323ED.5050708@hds.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      cf910e83
  4. 12 2月, 2013 3 次提交
  5. 24 1月, 2013 1 次提交
  6. 28 6月, 2012 1 次提交
    • A
      x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range · e7b52ffd
      Alex Shi 提交于
      x86 has no flush_tlb_range support in instruction level. Currently the
      flush_tlb_range just implemented by flushing all page table. That is not
      the best solution for all scenarios. In fact, if we just use 'invlpg' to
      flush few lines from TLB, we can get the performance gain from later
      remain TLB lines accessing.
      
      But the 'invlpg' instruction costs much of time. Its execution time can
      compete with cr3 rewriting, and even a bit more on SNB CPU.
      
      So, on a 512 4KB TLB entries CPU, the balance points is at:
      	(512 - X) * 100ns(assumed TLB refill cost) =
      		X(TLB flush entries) * 100ns(assumed invlpg cost)
      
      Here, X is 256, that is 1/2 of 512 entries.
      
      But with the mysterious CPU pre-fetcher and page miss handler Unit, the
      assumed TLB refill cost is far lower then 100ns in sequential access. And
      2 HT siblings in one core makes the memory access more faster if they are
      accessing the same memory. So, in the patch, I just do the change when
      the target entries is less than 1/16 of whole active tlb entries.
      Actually, I have no data support for the percentage '1/16', so any
      suggestions are welcomed.
      
      As to hugetlb, guess due to smaller page table, and smaller active TLB
      entries, I didn't see benefit via my benchmark, so no optimizing now.
      
      My micro benchmark show in ideal scenarios, the performance improves 70
      percent in reading. And in worst scenario, the reading/writing
      performance is similar with unpatched 3.4-rc4 kernel.
      
      Here is the reading data on my 2P * 4cores *HT NHM EP machine, with THP
      'always':
      
      multi thread testing, '-t' paramter is thread number:
      	       	        with patch   unpatched 3.4-rc4
      ./mprotect -t 1           14ns		24ns
      ./mprotect -t 2           13ns		22ns
      ./mprotect -t 4           12ns		19ns
      ./mprotect -t 8           14ns		16ns
      ./mprotect -t 16          28ns		26ns
      ./mprotect -t 32          54ns		51ns
      ./mprotect -t 128         200ns		199ns
      
      Single process with sequencial flushing and memory accessing:
      
      		       	with patch   unpatched 3.4-rc4
      ./mprotect		    7ns			11ns
      ./mprotect -p 4096  -l 8 -n 10240
      			    21ns		21ns
      
      [ hpa: http://lkml.kernel.org/r/1B4B44D9196EFF41AE41FDA404FC0A100BFF94@SHSMSX101.ccr.corp.intel.com
        has additional performance numbers. ]
      Signed-off-by: NAlex Shi <alex.shi@intel.com>
      Link: http://lkml.kernel.org/r/1340845344-27557-3-git-send-email-alex.shi@intel.comSigned-off-by: NH. Peter Anvin <hpa@zytor.com>
      e7b52ffd
  7. 25 6月, 2012 2 次提交
    • C
      x86/uv: Work around UV2 BAU hangs · 8b6e511e
      Cliff Wickman 提交于
      On SGI's UV2 the BAU (Broadcast Assist Unit) driver can hang
      under a heavy load. To cure this:
      
      - Disable the UV2 extended status mode (see UV2_EXT_SHFT), as
        this mode changes BAU behavior in more ways then just delivering
        an extra bit of status.  Revert status to just two meaningful bits,
        like UV1.
      
      - Use no IPI-style resets on UV2.  Just give up the request for
        whatever the reason it failed and let it be accomplished with
        the legacy IPI method.
      
      - Use no alternate sending descriptor (the former UV2 workaround
        bcp->using_desc and handle_uv2_busy() stuff).  Just disable the
        use of the BAU for a period of time in favor of the legacy IPI
        method when the h/w bug leaves a descriptor busy.
      
        -- new tunable: giveup_limit determines the threshold at which a hub is
           so plugged that it should do all requests with the legacy IPI method for a
           period of time
        -- generalize disable_for_congestion() (renamed disable_for_period()) for
           use whenever a hub should avoid using the BAU for a period of time
      
      Also:
      
       - Fix find_another_by_swack(), which is part of the UV2 bug workaround
      
       - Correct and clarify the statistics (new stats s_overipilimit, s_giveuplimit,
         s_enters, s_ipifordisabled, s_plugged, s_congested)
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      Link: http://lkml.kernel.org/r/20120622131459.GC31884@sgi.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      8b6e511e
    • C
      x86/uv: Implement UV BAU runtime enable and disable control via /proc/sgi_uv/ · 26ef8577
      Cliff Wickman 提交于
      This patch enables the BAU to be turned on or off dynamically.
      
        echo "on"  > /proc/sgi_uv/ptc_statistics
        echo "off" > /proc/sgi_uv/ptc_statistics
      
      The system may be booted with or without the nobau option.
      
      Whether the system currently has the BAU off can be seen in
      the /proc file -- normally with the baustats script.
      Each cpu will have a 1 in the bauoff field if the BAU was turned
      off, so baustats will give a count of cpus that have it off.
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      Link: http://lkml.kernel.org/r/20120622131330.GB31884@sgi.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      26ef8577
  8. 08 6月, 2012 1 次提交
  9. 26 1月, 2012 1 次提交
  10. 17 1月, 2012 3 次提交
  11. 05 12月, 2011 1 次提交
  12. 21 9月, 2011 1 次提交
    • J
      x86: uv2: Workaround for UV2 Hub bug (system global address format) · 6a469e46
      Jack Steiner 提交于
      This is a workaround for a UV2 hub bug that affects the format of system
      global addresses.
      
      The GRU API for UV2 was inadvertently broken by a hardware change.  The
      format of the physical address used for TLB dropins and for addresses used
      with instructions running in unmapped mode has changed.  This change was
      not documented and became apparent only when diags failed running on
      system simulators.
      
      For UV1, TLB and GRU instruction physical addresses are identical to
      socket physical addresses (although high NASID bits must be OR'ed into the
      address).
      
      For UV2, socket physical addresses need to be converted.  The NODE portion
      of the physical address needs to be shifted so that the low bit is in bit
      39 or bit 40, depending on an MMR value.
      
      It is not yet clear if this bug will be fixed in a silicon respin.  If it
      is fixed, the hub revision will be incremented & the workaround disabled.
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      6a469e46
  13. 30 8月, 2011 1 次提交
  14. 21 6月, 2011 4 次提交
  15. 30 5月, 2011 1 次提交
    • J
      x86, UV: Clean up uv_mmrs.h · 55ba4120
      Jack Steiner 提交于
      No code changes. Reformat definitions to make it more readable.
      
      I fixed alignment of comments in the structure definitions.
      
      Also aligned comments and most field definitions & values. Also
      sorted the defines for the SHIFT & MASK values for each MMR.
      This make the file visually much more acceptable.
      
      Some of the symbol names are still quite long. The file is based
      on post-processing of verilog definitions that are used for the
      node controller chip design. Although some symbol names are not
      what I would chose, I would like to maintain compatibility with
      the names used by the chip designers. We have a number of
      cross-reference utilities & having common names is important.
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      Link: http://lkml.kernel.org/r/20110527145256.GA31224@sgi.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
      --
       arch/x86/include/asm/uv/uv_mmrs.h | 2873 +++++++++++++++++++++-----------------
       1 file changed, 1600 insertions(+), 1273 deletions(-)
      55ba4120
  16. 25 5月, 2011 2 次提交
    • C
      x86, UV: Clean up uv_tlb.c · f073cc8f
      Cliff Wickman 提交于
      SGI UV's uv_tlb.c driver has become rather hard to read, with overly large
      functions, non-standard coding style and (way) too long variable, constant
      and function names and non-obvious code flow sequences.
      
      This patch improves the readability and maintainability of the driver
      significantly, by doing the following strict code cleanups with no side
      effects:
      
       - Split long functions into shorter logical functions.
      
       - Shortened some variable and structure member names.
      
       - Added special functions for reads and writes of MMR regs with
         very long names.
      
       - Added the 'tunables' table to shortened tunables_write().
      
       - Added the 'stat_description' table to shorten uv_ptc_proc_write().
      
       - Pass fewer 'stat' arguments where it can be derived from the 'bcp'
         argument.
      
       - Function definitions consistent on one line, and inline in few (short) cases.
      
       - Moved some small structures and an atomic inline function to the header file.
      
       - Moved some local variables to the blocks where they are used.
      
       - Updated the copyright date.
      
       - Shortened uv_write_global_mmr64() etc. using some aliasing; no
         line breaks. Renamed many uv_.. functions that are not exported.
      
       - Aligned structure fields.
          [ note that not all structures are aligned the same way though; I'd like
            to keep the extensive commenting in some of them. ]
      
       - Shortened some long structure names.
      
       - Standard pass/fail exit from init_per_cpu()
      
       - Vertical alignment for mass initializations.
      
       - More separation between blocks of code.
      
      Tested on a 16-processor Altix UV.
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      Cc: penberg@kernel.org
      Link: http://lkml.kernel.org/r/E1QOw12-0004MN-Lp@eag09.americas.sgi.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
      f073cc8f
    • J
      x86, UV: Add support for SGI UV2 hub chip · 2a919596
      Jack Steiner 提交于
      This patch adds support for a new version of the SGI UV hub
      chip. The hub chip is the node controller that connects multiple
      blades into a larger coherent SSI.
      
      For the most part, UV2 is compatible with UV1. The majority of
      the changes are in the addresses of MMRs and in a few cases, the
      contents of MMRs. These changes are the result in changes in the
      system topology such as node configuration, processor types,
      maximum nodes, physical address sizes, etc.
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      Link: http://lkml.kernel.org/r/20110511175028.GA18006@sgi.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
      2a919596
  17. 13 5月, 2011 1 次提交
    • C
      x86: Fix UV BAU for non-consecutive nasids · 77ed23f8
      Cliff Wickman 提交于
      This is a fix for the SGI Altix-UV Broadcast Assist Unit code,
      which is used for TLB flushing.
      
      Certain hardware configurations (that customers are ordering)
      cause nasids (numa address space id's) to be non-consecutive.
      Specifically, once you have more than 4 blades in a IRU
      (Individual Rack Unit - or 1/2 rack) but less than the maximum
      of 16, the nasid numbering becomes non-consecutive.  This
      currently results in a 'catastrophic error' (CATERR) detected by
      the firmware during OS boot.  The BAU is generating an 'INTD'
      request that is targeting a non-existent nasid value. Such
      configurations may also occur when a blade is configured off
      because of hardware errors. (There is one UV hub per blade.)
      
      This patch is required to support such configurations.
      
      The problem with the tlb_uv.c code is that is using the
      consecutive hub numbers as indices to the BAU distribution bit
      map. These are simply the ordinal position of the hub or blade
      within its partition.  It should be using physical node numbers
      (pnodes), which correspond to the physical nasid values. Use of
      the hub number only works as long as the nasids in the partition
      are consecutive and increase with a stride of 1.
      
      This patch changes the index to be the pnode number, thus
      allowing nasids to be non-consecutive.
      It also provides a table in local memory for each cpu to
      translate target cpu number to target pnode and nasid.
      And it improves naming to properly reflect 'node' and 'uvhub'
      versus 'nasid'.
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      Cc: <stable@kernel.org>
      Link: http://lkml.kernel.org/r/E1QJmxX-0002Mz-Fk@eag09.americas.sgi.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
      77ed23f8
  18. 10 5月, 2011 1 次提交
    • J
      x86, UV: Fix NMI handler for UV platforms · 1d44e828
      Jack Steiner 提交于
      This fixes problems seen on UV systems handling NMIs from the
      node controller.
      
      I isolated the "dazed..." messages that I saw earlier to a bug in
      the BMC on our platform. It was sending NMIs w/o properly setting
      a register that indicated the source of NMI.
      
      So rather than _assuming_ any unhandled NMI came from the UV system
      maintenance console (SMC), add a check to verify that the SMC actually
      sent the NMI.
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      Cc: gorcunov@gmail.com
      Cc: dzickus@redhat.com
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1d44e828
  19. 09 3月, 2011 1 次提交
  20. 04 1月, 2011 1 次提交
    • C
      x86, UV, BAU: Extend for more than 16 cpus per socket · cfa60917
      Cliff Wickman 提交于
      Fix a hard-coded limit of a maximum of 16 cpu's per socket.
      
      The UV Broadcast Assist Unit code initializes by scanning the
      cpu topology of the system and assigning a master cpu for each
      socket and UV hub. That scan had an assumption of a limit of 16
      cpus per socket. With Westmere we are going over that limit.
      The UV hub hardware will allow up to 32.
      
      If the scan finds the system has gone over that limit it returns
      an error and we print a warning and fall back to doing TLB
      shootdowns without the BAU.
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      Cc: <stable@kernel.org> # .37.x
      LKML-Reference: <E1PZol7-0000mM-77@eag09.americas.sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      cfa60917
  21. 18 11月, 2010 1 次提交
    • D
      x86: UV: Address interrupt/IO port operation conflict · 8191c9f6
      Dimitri Sivanich 提交于
      This patch for SGI UV systems addresses a problem whereby
      interrupt transactions being looped back from a local IOH,
      through the hub to a local CPU can (erroneously) conflict with
      IO port operations and other transactions.
      
      To workaound this we set a high bit in the APIC IDs used for
      interrupts. This bit appears to be ignored by the sockets, but
      it avoids the conflict in the hub.
      Signed-off-by: NDimitri Sivanich <sivanich@sgi.com>
      LKML-Reference: <20101116222352.GA8155@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ___
      
       arch/x86/include/asm/uv/uv_hub.h   |    4 ++++
       arch/x86/include/asm/uv/uv_mmrs.h  |   19 ++++++++++++++++++-
       arch/x86/kernel/apic/x2apic_uv_x.c |   25 +++++++++++++++++++++++--
       arch/x86/platform/uv/tlb_uv.c      |    2 +-
       arch/x86/platform/uv/uv_time.c     |    4 +++-
       5 files changed, 49 insertions(+), 5 deletions(-)
      8191c9f6
  22. 10 11月, 2010 1 次提交
    • J
      x86, UV: Update node controller MMRs · 62b0cfc2
      Jack Steiner 提交于
      A new version of the SGI UV hub node controller is being
      developed. A few of the MMRs (control registers) that exist on
      the current hub no longer exist on the new hub. Fortunately,
      there are alternate MMRs that are are functionally equivalent
      and that exist on both hubs.
      
      This patch changes the UV code to use MMRs that exist in BOTH
      versions of the hub node controller.
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      LKML-Reference: <20101106204056.GA27584@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      62b0cfc2
  23. 27 10月, 2010 1 次提交
  24. 09 6月, 2010 6 次提交
    • C
      x86, UV: Modularize BAU send and wait · f6d8a566
      Cliff Wickman 提交于
      Streamline the large uv_flush_send_and_wait() function by use of
      a couple of helper functions.
      
      And remove some excess comments.
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      Cc: gregkh@suse.de
      LKML-Reference: <E1OJvNy-0004ay-IH@eag09.americas.sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f6d8a566
    • C
      x86, UV: BAU broadcast to the local hub · 450a007e
      Cliff Wickman 提交于
      Make the Broadcast Assist Unit driver use the BAU for TLB
      shootdowns of cpu's on the local uvhub.
      
      It was previously thought that IPI might be faster to the cpu's
      on the local hub.  But the IPI operation would have to follow
      the completion of the BAU broadcast anyway.  So we broadcast to
      the local uvhub in all cases except when the current cpu was the
      only local cpu in the mask.
      
      This simplifies uv_flush_send_and_wait() in that it returns
      either all shootdowns complete, or none.
      
      Adjust the statistics to account for shootdowns on the local
      uvhub.
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      Cc: gregkh@suse.de
      LKML-Reference: <E1OJvNy-0004aq-G7@eag09.americas.sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      450a007e
    • C
      x86, UV: Remove BAU check for stay-busy · 90cc7d94
      Cliff Wickman 提交于
      Remove a faulty assumption that a long running BAU request has
      encountered a hardware problem and will never finish.
      
      Numalink congestion can make a request appear to have
      encountered such a problem, but it is not safe to cancel the
      request.  If such a cancel is done but a reply is later received
      we can miss a TLB shootdown.
      
      We depend upon the max_bau_concurrent 'throttle' to prevent the
      stay-busy case from happening.
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      Cc: gregkh@suse.de
      LKML-Reference: <E1OJvNy-0004ad-BV@eag09.americas.sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      90cc7d94
    • C
      x86, UV: BAU structure rearranging · 4faca155
      Cliff Wickman 提交于
      Move some structure definitions from the C code to the BAU
      header file, and change the organization of that header file a
      little.
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      Cc: gregkh@suse.de
      LKML-Reference: <E1OJvNy-0004aI-54@eag09.americas.sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4faca155
    • C
      x86, UV: Shorten access to BAU statistics structure · 712157aa
      Cliff Wickman 提交于
      Use a pointer from the per-cpu BAU control structure to the
      per-cpu BAU statistics structure.
      We nearly always know the first before needing the second.
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      Cc: gregkh@suse.de
      LKML-Reference: <E1OJvNy-0004aB-2k@eag09.americas.sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      712157aa
    • C
      x86, UV: Disable BAU on network congestion · 50fb55ac
      Cliff Wickman 提交于
      The numalink network can become so congested that TLB shootdown
      using the Broadcast Assist Unit becomes slower than using IPI's.
      
      In that case, disable the use of the BAU for a period of time.
      The period is tunable.  When the period expires the use of the
      BAU is re-enabled. A count of these actions is added to the
      statistics file.
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      Cc: gregkh@suse.de
      LKML-Reference: <E1OJvNy-0004a4-0a@eag09.americas.sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      50fb55ac