Skip to content
Snippets Groups Projects
  1. May 13, 2015
    • Jiang Liu's avatar
      x86, irq: Allocate CPU vectors from device local CPUs if possible · 486ca539
      Jiang Liu authored
      
      On NUMA systems, an IO device may be associated with a NUMA node.
      It may improve IO performance to allocate resources, such as memory
      and interrupts, from device local node.
      
      This patch introduces a mechanism to support CPU vector allocation
      policies. It tries to allocate CPU vectors from CPUs on device local
      node first, and then fallback to all online(global) CPUs.
      
      This mechanism may be used to support NumaConnect systems to allocate
      CPU vectors from device local node.
      
      Signed-off-by: default avatarJiang Liu <jiang.liu@linux.intel.com>
      Tested-by: default avatarDaniel J Blueman <daniel@numascale.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Link: http://lkml.kernel.org/r/1430967244-28905-1-git-send-email-jiang.liu@linux.intel.com
      
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      486ca539
    • Sergey Senozhatsky's avatar
      x86/hpet: Pass proper pointer to irq_alloc_info · 4a00c95d
      Sergey Senozhatsky authored
      
      Fix the following oops:
       hpet_msi_get_hwirq+0x1f/0x27
       msi_domain_alloc+0x35/0xfe
       ? trace_hardirqs_on_caller+0x16c/0x188
       irq_domain_alloc_irqs_recursive+0x51/0x95
       __irq_domain_alloc_irqs+0x151/0x223
       hpet_assign_irq+0x5d/0x68
       hpet_msi_capability_lookup+0x121/0x1cb
       ? hpet_enable+0x2b4/0x2b4
       hpet_late_init+0x5f/0xf2
       ? hpet_enable+0x2b4/0x2b4
       do_one_initcall+0x184/0x199
       kernel_init_freeable+0x1af/0x237
       ? rest_init+0x13a/0x13a
       kernel_init+0xe/0xd4
       ret_from_fork+0x3f/0x70
       ? rest_init+0x13a/0x13a
      
      Since 3cb96f0c ('x86/hpet: Enhance HPET IRQ to support
      hierarchical irqdomains') hpet_msi_capability_lookup() uses
      hpet_assign_irq(). The latter initializes irq_alloc_info on stack, but
      passes a NULL pointer to irq_domain_alloc_irqs(), which causes a NULL
      pointer dereference later in hpet_msi_get_hwirq().
      
      Pass the pointer to the irq_alloc_info irq_domain_alloc_irqs().
      
      Fixes: 3cb96f0c 'x86/hpet: Enhance HPET IRQ to support hierarchical irqdomains'
      Signed-off-by: default avatarSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Reviewed-by: default avatarJiang Liu <jiang.liu@linux.intel.com>
      Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
      Link: http://lkml.kernel.org/r/20150512041444.GA1094@swordfish
      
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      4a00c95d
    • Ingo Molnar's avatar
      Revert f5d6a52f ("x86/smpboot: Skip delays during SMP initialization similar to Xen") · 853b160a
      Ingo Molnar authored
      
      Huang Ying reported x86 boot hangs due to this commit.
      
      Turns out that the change, despite its changelog, does more
      than just change timeouts: it also changes the way we
      assert/deassert INIT via the APIC_DM_INIT IPI, in the x2apic
      case it skips the deassert step.
      
      This is historically fragile code and the patch did not
      improve it, so revert these changes.
      
      This commit:
      
        1a744cb3 ("x86/smp/boot: Remove 10ms delay from cpu_up() on modern processors")
      
      independently removes the worst of the delays (the 10 msec delay).
      
      The remaining delays can be addressed one by one, combined
      with careful testing.
      
      Reported-by: default avatarHuang Ying <ying.huang@intel.com>
      Cc: Anthony Liguori <aliguori@amazon.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Gang Wei <gang.wei@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jan H. Schönherr <jschoenh@amazon.de>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tim Deegan <tim@xen.org>
      Link: http://lkml.kernel.org/r/1430732554-7294-1-git-send-email-jschoenh@amazon.de
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      853b160a
  2. May 12, 2015
  3. May 11, 2015
    • Borislav Petkov's avatar
      x86/alternatives: Switch AMD F15h and later to the P6 NOPs · f21262b8
      Borislav Petkov authored
      
      Software optimization guides for both F15h and F16h cite those
      NOPs as the optimal ones. A microbenchmark confirms that
      actually even older families are better with the single-insn
      NOPs so switch to them for the alternatives.
      
      Cycles count below includes the loop overhead of the measurement
      but that overhead is the same with all runs.
      
      	F10h, revE:
      	-----------
      	Running NOP tests, 1000 NOPs x 1000000 repetitions
      
      	K8:
      			      90     288.212282 cycles
      			   66 90     288.220840 cycles
      			66 66 90     288.219447 cycles
      		     66 66 66 90     288.223204 cycles
      		  66 66 90 66 90     571.393424 cycles
      	       66 66 90 66 66 90     571.374919 cycles
      	    66 66 66 90 66 66 90     572.249281 cycles
      	 66 66 66 90 66 66 66 90     571.388651 cycles
      
      	P6:
      			      90     288.214193 cycles
      			   66 90     288.225550 cycles
      			0f 1f 00     288.224441 cycles
      		     0f 1f 40 00     288.225030 cycles
      		  0f 1f 44 00 00     288.233558 cycles
      	       66 0f 1f 44 00 00     324.792342 cycles
      	    0f 1f 80 00 00 00 00     325.657462 cycles
      	 0f 1f 84 00 00 00 00 00     430.246643 cycles
      
      	F14h:
      	----
      	Running NOP tests, 1000 NOPs x 1000000 repetitions
      
      	K8:
      			      90     510.404890 cycles
      			   66 90     510.432117 cycles
      			66 66 90     510.561858 cycles
      		     66 66 66 90     510.541865 cycles
      		  66 66 90 66 90    1014.192782 cycles
      	       66 66 90 66 66 90    1014.226546 cycles
      	    66 66 66 90 66 66 90    1014.334299 cycles
      	 66 66 66 90 66 66 66 90    1014.381205 cycles
      
      	P6:
      			      90     510.436710 cycles
      			   66 90     510.448229 cycles
      			0f 1f 00     510.545100 cycles
      		     0f 1f 40 00     510.502792 cycles
      		  0f 1f 44 00 00     510.589517 cycles
      	       66 0f 1f 44 00 00     510.611462 cycles
      	    0f 1f 80 00 00 00 00     511.166794 cycles
      	 0f 1f 84 00 00 00 00 00     511.651641 cycles
      
      	F15h:
      	-----
      	Running NOP tests, 1000 NOPs x 1000000 repetitions
      
      	K8:
      			      90     243.128396 cycles
      			   66 90     243.129883 cycles
      			66 66 90     243.131631 cycles
      		     66 66 66 90     242.499324 cycles
      		  66 66 90 66 90     481.829083 cycles
      	       66 66 90 66 66 90     481.884413 cycles
      	    66 66 66 90 66 66 90     481.851446 cycles
      	 66 66 66 90 66 66 66 90     481.409220 cycles
      
      	P6:
      			      90     243.127026 cycles
      			   66 90     243.130711 cycles
      			0f 1f 00     243.122747 cycles
      		     0f 1f 40 00     242.497617 cycles
      		  0f 1f 44 00 00     245.354461 cycles
      	       66 0f 1f 44 00 00     361.930417 cycles
      	    0f 1f 80 00 00 00 00     362.844944 cycles
      	 0f 1f 84 00 00 00 00 00     480.514948 cycles
      
      	F16h:
      	-----
      	Running NOP tests, 1000 NOPs x 1000000 repetitions
      
      	K8:
      			      90     507.793298 cycles
      			   66 90     507.789636 cycles
      			66 66 90     507.826490 cycles
      		     66 66 66 90     507.859075 cycles
      		  66 66 90 66 90    1008.663129 cycles
      	       66 66 90 66 66 90    1008.696259 cycles
      	    66 66 66 90 66 66 90    1008.692517 cycles
      	 66 66 66 90 66 66 66 90    1008.755399 cycles
      
      	P6:
      			      90     507.795232 cycles
      			   66 90     507.794761 cycles
      			0f 1f 00     507.834901 cycles
      		     0f 1f 40 00     507.822629 cycles
      		  0f 1f 44 00 00     507.838493 cycles
      	       66 0f 1f 44 00 00     507.908597 cycles
      	    0f 1f 80 00 00 00 00     507.946417 cycles
      	 0f 1f 84 00 00 00 00 00     507.954960 cycles
      
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1431332153-18566-2-git-send-email-bp@alien8.de
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      f21262b8
  4. May 10, 2015
  5. May 08, 2015
  6. May 06, 2015
  7. May 05, 2015
  8. Apr 27, 2015
  9. Apr 24, 2015