1. 24 Feb, 2009 1 commit
    • Salman Qazi's avatar
      x86: fix performance regression in write() syscall · 30d697fa
      Salman Qazi authored
      While the introduction of __copy_from_user_nocache (see commit:
      0812a579) may have been an improvement
      for sufficiently large writes, there is evidence to show that it is
      deterimental for small writes.  Unixbench's fstime test gives the
      following results for 256 byte writes with MAX_BLOCK of 2000:
      
          2.6.29-rc6 ( 5 samples, each in KB/sec ):
          283750, 295200, 294500, 293000, 293300
      
          2.6.29-rc6 + this patch (5 samples, each in KB/sec):
          313050, 3106750, 293350, 306300, 307900
      
          2.6.18
          395700, 342000, 399100, 366050, 359850
      
          See w_test() in src/fstime.c in unixbench version 4.1.0.  Basically, the above test
          consists of counting how much we can write in this manner:
      
          alarm(10);
          while (!sigalarm) {
                  for (f_blocks = 0; f_blocks < 2000; ++f_blocks) {
                         write(f, buf, 256);
                  }
                  lseek(f, 0L, 0);
          }
      
      Note, there are other components to the write syscall regression
      that are not addressed here.
      Signed-off-by: default avatarSalman Qazi <sqazi@google.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      30d697fa
  2. 19 Feb, 2009 6 commits
  3. 17 Feb, 2009 3 commits
  4. 16 Feb, 2009 6 commits
  5. 15 Feb, 2009 5 commits
    • Yinghai Lu's avatar
      [IA64] fix __apci_unmap_table · 970ec1a8
      Yinghai Lu authored
      Impact: fix build error
      
      to fix:
      
        tip/arch/ia64/kernel/acpi.c:203: error: conflicting types for '__acpi_unmap_table'
        tip/include/linux/acpi.h:82: error: previous declaration of '__acpi_unmap_table' was here
        tip/arch/ia64/kernel/acpi.c:203: error: conflicting types for '__acpi_unmap_table'
        tip/include/linux/acpi.h:82: error: previous declaration of '__acpi_unmap_table' was here
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      970ec1a8
    • Yinghai Lu's avatar
      x86: make 32bit to call enable_IO_APIC early like 64bit · 88d0f550
      Yinghai Lu authored
      Impact: cleanup
      
      So we remove some #ifdefs.
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      88d0f550
    • Thomas Gleixner's avatar
      x86, vm86: fix preemption bug · be716615
      Thomas Gleixner authored
      Commit 3d2a71a5 ("x86, traps: converge
      do_debug handlers") changed the preemption disable logic of do_debug()
      so vm86_handle_trap() is called with preemption disabled resulting in:
      
       BUG: sleeping function called from invalid context at include/linux/kernel.h:155
       in_atomic(): 1, irqs_disabled(): 0, pid: 3005, name: dosemu.bin
       Pid: 3005, comm: dosemu.bin Tainted: G        W  2.6.29-rc1 #51
       Call Trace:
        [<c050d669>] copy_to_user+0x33/0x108
        [<c04181f4>] save_v86_state+0x65/0x149
        [<c0418531>] handle_vm86_trap+0x20/0x8f
        [<c064e345>] do_debug+0x15b/0x1a4
        [<c064df1f>] debug_stack_correct+0x27/0x2c
        [<c040365b>] sysenter_do_call+0x12/0x2f
       BUG: scheduling while atomic: dosemu.bin/3005/0x10000001
      
      Restore the original calling convention and reenable preemption before
      calling handle_vm86_trap().
      Reported-by: default avatarMichal Suchanek <hramrach@centrum.cz>
      Cc: stable@kernel.org
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      be716615
    • Yinghai Lu's avatar
      x86: fix typo in filter_cpuid_features() · f6db44df
      Yinghai Lu authored
      Impact: fix wrong disabling of cpu features
      
      an amd system got this strange output:
      
       CPU: CPU feature monitor disabled due to lack of CPUID level 0x5
      
      but in /proc/cpuinfo I have:
      
       cpuid level	: 5
      
      on intel system:
      
       CPU: CPU feature monitor disabled due to lack of CPUID level 0x5
       CPU: CPU feature dca disabled due to lack of CPUID level 0x9
      
      but in /proc/cpuinfo i have:
      
       cpuid level     : 11
      
      Tt turns out there is a typo, and we should use level member in df.
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      f6db44df
    • Ingo Molnar's avatar
      Merge commit 'v2.6.29-rc5' into x86/apic · b69bc396
      Ingo Molnar authored
      b69bc396
  6. 14 Feb, 2009 1 commit
  7. 13 Feb, 2009 18 commits