1. 01 4月, 2006 1 次提交
    • O
      [PATCH] Don't pass boot parameters to argv_init[] · 9b41046c
      OGAWA Hirofumi 提交于
      The boot cmdline is parsed in parse_early_param() and
      parse_args(,unknown_bootoption).
      
      And __setup() is used in obsolete_checksetup().
      
      	start_kernel()
      		-> parse_args()
      			-> unknown_bootoption()
      				-> obsolete_checksetup()
      
      If __setup()'s callback (->setup_func()) returns 1 in
      obsolete_checksetup(), obsolete_checksetup() thinks a parameter was
      handled.
      
      If ->setup_func() returns 0, obsolete_checksetup() tries other
      ->setup_func().  If all ->setup_func() that matched a parameter returns 0,
      a parameter is seted to argv_init[].
      
      Then, when runing /sbin/init or init=app, argv_init[] is passed to the app.
      If the app doesn't ignore those arguments, it will warning and exit.
      
      This patch fixes a wrong usage of it, however fixes obvious one only.
      Signed-off-by: NOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9b41046c
  2. 28 3月, 2006 1 次提交
    • S
      [PATCH] sched: new sched domain for representing multi-core · 1e9f28fa
      Siddha, Suresh B 提交于
      Add a new sched domain for representing multi-core with shared caches
      between cores.  Consider a dual package system, each package containing two
      cores and with last level cache shared between cores with in a package.  If
      there are two runnable processes, with this appended patch those two
      processes will be scheduled on different packages.
      
      On such systems, with this patch we have observed 8% perf improvement with
      specJBB(2 warehouse) benchmark and 35% improvement with CFP2000 rate(with 2
      users).
      
      This new domain will come into play only on multi-core systems with shared
      caches.  On other systems, this sched domain will be removed by domain
      degeneration code.  This new domain can be also used for implementing power
      savings policy (see OLS 2005 CMP kernel scheduler paper for more details..
      I will post another patch for power savings policy soon)
      
      Most of the arch/* file changes are for cpu_coregroup_map() implementation.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1e9f28fa
  3. 26 3月, 2006 8 次提交
  4. 24 3月, 2006 1 次提交
    • A
      [PATCH] x86_64: {set,clear,test}_bit() related cleanup and pci_mmcfg_init() fix · 3d1712c9
      Akinobu Mita 提交于
      While working on these patch set, I found several possible cleanup on x86-64
      and ia64.
      
      akpm: I stole this from Andi's queue.
      
      Not only does it clean up bitops.  It also unrelatedly changes the prototype
      of pci_mmcfg_init() and removes its arch_initcall().  It seems that the wrong
      two patches got joined together, but this is the one which has been tested.
      
      This patch fixes the current x86_64 build error (the pci_mmcfg_init()
      declaration in arch/i386/pci/pci.h disagrees with the definition in
      arch/x86_64/pci/mmconfig.c)
      
      This also means that x86_64's pci_mmcfg_init() gets called in the same (new)
      manner as x86's: from arch/i386/pci/init.c:pci_access_init(), rather than via
      initcall.
      
      The bitops cleanups came along for free.
      
      All this worked OK in -mm testing (since 2.6.16-rc4-mm1) because x86_64 was
      tested with both patches applied.
      Signed-off-by: NAkinobu Mita <mita@miraclelinux.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Cc: Con Kolivas <kernel@kolivas.org>
      Cc: Jean Delvare <khali@linux-fr.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3d1712c9
  5. 27 2月, 2006 2 次提交
  6. 08 2月, 2006 1 次提交
  7. 05 2月, 2006 2 次提交
    • J
      [PATCH] x86_64: IOMMU printk cleanup · 5b7b644c
      Jon Mason 提交于
      This patch contains a printk reorder to remove the current problem of
      displaying "PCI-DMA: Disabling IOMMU." and then "PCI-DMA: using GART
      IOMMU" 20 lines later in dmesg.
      
      It also constains a printk reorder in swiotlb to state swiotlb
      enablement prior to describing the location of the bounce buffers, and a
      printk reorder to state gart enablement prior to describing the
      aperature.
      
      Also constains a whitespace cleanup in arch/x86_64/kernel/setup.c
      
      Tested (along with patch 2/2) on dual opteron with gart enabled,
      iommu=soft, and iommu=off.
      Signed-off-by: NJon Mason <jdmason@us.ibm.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5b7b644c
    • A
      [PATCH] x86_64: Undo the earlier changes to remove unrolled copy/memset functions · 7bcd3f34
      Andi Kleen 提交于
      They cause quite bad performance regressions on Netburst
      This is temporary until we can get new optimized functions
      for these CPUs.
      
      This undoes changes that were done in 2.6.15 and in 2.6.16-rc1,
      essentially bringing the code back to 2.6.14 level. Only change
      is I renamed the X86_FEATURE_K8_C flag to X86_FEATURE_REP_GOOD
      and fixed the check for the flag and also fixed some comments.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7bcd3f34
  8. 12 1月, 2006 12 次提交
  9. 11 1月, 2006 2 次提交
  10. 07 12月, 2005 1 次提交
    • V
      [CPUFREQ] CPU frequency display in /proc/cpuinfo · 95235ca2
      Venkatesh Pallipadi 提交于
      What is the value shown in "cpu MHz" of /proc/cpuinfo when CPUs are capable of
      changing frequency?
      
      Today the answer is: It depends.
      On i386:
      SMP kernel - It is always the boot frequency
      UP kernel - Scales with the frequency change and shows that was last set.
      
      On x86_64:
      There is one single variable cpu_khz that gets written by all the CPUs. So,
      the frequency set by last CPU will be seen on /proc/cpuinfo of all the
      CPUs in the system. What you see also depends on whether you have constant_tsc
      capable CPU or not.
      
      On ia64:
      It is always boot time frequency of a particular CPU that gets displayed.
      
      The patch below changes this to:
      Show the last known frequency of the particular CPU, when cpufreq is present. If
      cpu doesnot support changing of frequency through cpufreq, then boot frequency
      will be shown. The patch affects i386, x86_64 and ia64 architectures.
      
      Signed-off-by: Venkatesh Pallipadi<venkatesh.pallipadi@intel.com>
      Signed-off-by: NDave Jones <davej@redhat.com>
      95235ca2
  11. 15 11月, 2005 7 次提交
  12. 31 10月, 2005 1 次提交
  13. 04 10月, 2005 1 次提交