Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
大约 1 年 前同步成功

通知 158
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 27 6月, 2006 2 次提交
  3. 23 6月, 2006 2 次提交
  5. 16 5月, 2006 1 次提交
  7. 28 4月, 2006 2 次提交
    • A
      [PATCH] Mark VMSPLIT EMBEDDED · 9539d4e7
      由 Andi Kleen 提交于 
      Running abnormal VM splits causes weird problems - people can set non-standard
splits by accident, then lots of time gets wasted diagnosing it - see the long
"[stable] 2.6.16.6 breaks java...  sort of" email thread.

So we need to make this option harder to set.  Use CONFIG_EMBEDDED for this.

CONFIG_EMBEDDED isn't really the right thing to use, but there's nothing else
obvious and avoiding these problems is more important than Kconfig purity.
Signed-off-by: NAndi Kleen <ak@suse.de>
Cc: Adrian Bunk <bunk@stusta.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9539d4e7
    • A
      [PATCH] enable X86_PC for HOTPLUG_CPU · 35076bdf
      由 Ashok Raj 提交于 
      CPU_HOTPLUG has race conditions when we use broadcast mode IPI.

- First we introduced no_broadcast option
    (see include/asm-i386/mach-default/mach_ipi.h)

- x86_64 solved it by using physical flat mode (same as bigsmp on i386)
  since this will not use broadcast shortcuts for IPI.

- We switched to use bigsmp on i386 so that we can have same handling as
  x86_64, but apparently this caused an error message, if kernel was
  compiled without X86_GENERICARCH, X86_BIGSMP.  The message "You have >8
  CPUS..." which was bogus and misleading, and only indicated one of the
  above ARCH wasnt selected.

So we do not switch to automatic bigsmp for HOTPLUG_CPU support in i386
until the other related config dependencies for SMP_SUSPEND etc can be done
right.
Signed-off-by: NAshok Raj <ashok.raj@intel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      35076bdf
  9. 11 4月, 2006 3 次提交
  11. 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
  13. 27 3月, 2006 1 次提交
  15. 26 3月, 2006 1 次提交
    • A
      [PATCH] x86: make CONFIG_HOTPLUG_CPU depend on !X86_PC · d3f4aaa3
      由 Ashok Raj 提交于 
      Make CONFIG_HOTPLUG_CPU depend on !X86_PC, so we need to turn on either
CONFIG_GENERICARCH, CONFIG_BIGSMP or any other subarch except X86_PC when
CONFIG_HOTPLUG_CPU=y

With 2.6.15+ kernels when CONFIG_HOTPLUG_CPU is turned on we switch to
bigsmp mode for sending IPI's and ioapic configurations that caused the
following error message.

>> More than 8 CPUs detected and CONFIG_X86_PC cannot handle it.
>> Use CONFIG_X86_GENERICARCH or CONFIG_X86_BIGSMP.

Originally bigsmp was added just to handle >8 cpus, but now with hotplug
cpu support we need to use bigsmp mode (why?  see below), that cause the
above error message even if there were less than 8 cpus in the system.

The message is bogus, but we are cannot use logical flat mode due to issues
with broadcast IPI can confuse a CPU just comming up.  We use flat physical
mode just like x86_64 case.  More details on why bigsmp now uses flat
physical mode (vs.  cluster mode) in following link.

http://marc.theaimsgroup.com/?l=linux-kernel&m=113261865814107&w=2Signed-off-by: NAshok Raj <ashok.raj@intel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d3f4aaa3
  17. 23 3月, 2006 3 次提交
  19. 27 2月, 2006 2 次提交
  21. 06 2月, 2006 1 次提交
  23. 02 2月, 2006 2 次提交
    • M
      [PATCH] VMSPLIT config options · 975b3d3d
      由 Mark Lord 提交于 
      Enable selection of different user/kernel VM splits for i386, including an
optimized mode for 1GB physical RAM, which gives the kernel a direct (non
HIGHMEM) mapping to the entire 1GB rather than just the first 896MB.

There is a similarly a similarly optimized mode for machines with exactly 2GB
of physical RAM.

This can speed up the kernel by avoiding having to create/destroy temporary
HIGHMEM mappings, and by not having to include HIGHMEM support at all on such
machines.  The flip side is that there's less virtual addressing left for
userspace in these alternatives, and some binary-only kernel modules may
misbehave unless rebuilt with the same VMSPLIT option as the main kernel
image.

Original idea/patch from Jens Axboe, modified based on suggestions from Linus
et al.
Signed-off-by: NMark Lord <mlord@pobox.com>
Signed-off-by: NJens Axboe <axboe@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      975b3d3d
    • I
      [PATCH] CONFIG_DOUBLEFAULT Kconfig fix · 389d1ea5
      由 Ingo Molnar 提交于 
      Move CONFIG_DOUBLEFAULT from the main Kconfig menu (!) into its proper
place: the "Processor Type and features" submenu.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      389d1ea5
  25. 15 1月, 2006 1 次提交
  27. 12 1月, 2006 2 次提交
  29. 11 1月, 2006 2 次提交
  31. 09 1月, 2006 3 次提交
  33. 07 1月, 2006 1 次提交
  35. 14 11月, 2005 1 次提交
  37. 07 11月, 2005 1 次提交
  39. 01 11月, 2005 1 次提交
  41. 31 10月, 2005 3 次提交
  43. 15 9月, 2005 1 次提交
    • D
      [LIB]: Consolidate _atomic_dec_and_lock() · 4db2ce01
      由 David S. Miller 提交于 
      Several implementations were essentialy a common piece of C code using
the cmpxchg() macro.  Put the implementation in one spot that everyone
can share, and convert sparc64 over to using this.

Alpha is the lone arch-specific implementation, which codes up a
special fast path for the common case in order to avoid GP reloading
which a pure C version would require.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4db2ce01
  45. 08 9月, 2005 2 次提交
    • V
      [PATCH] Kconfig fix (BLK_DEV_FD dependencies) · a08b6b79
      由 viro@ZenIV.linux.org.uk 提交于 
      Sanitized and fixed floppy dependencies: split the messy dependencies for
BLK_DEV_FD by introducing a new symbol (ARCH_MAY_HAVE_PC_FDC), making
BLK_DEV_FD depend on that one and taking declarations of ARCH_MAY_HAVE_PC_FDC
to arch/*/Kconfig.  While we are at it, fixed several obvious cases when
BLK_DEV_FD should have been excluded (architectures lacking asm/floppy.h
are *not* going to have floppy.c compile, let alone work).

If you can come up with better name for that ("this architecture might
have working PC-compatible floppy disk controller"), you are more than
welcome - just s/ARCH_MAY_HAVE_PC_FDC/your_prefered_name/g in the patch
below...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a08b6b79
    • A
      [PATCH] x86/x86_64: deferred handling of writes to /proc/irqxx/smp_affinity · 54d5d424
      由 Ashok Raj 提交于 
      When handling writes to /proc/irq, current code is re-programming rte
entries directly. This is not recommended and could potentially cause
chipset's to lockup, or cause missing interrupts.

CONFIG_IRQ_BALANCE does this correctly, where it re-programs only when the
interrupt is pending. The same needs to be done for /proc/irq handling as well.
Otherwise user space irq balancers are really not doing the right thing.

- Changed pending_irq_balance_cpumask to pending_irq_migrate_cpumask for
  lack of a generic name.
- added move_irq out of IRQ_BALANCE, and added this same to X86_64
- Added new proc handler for write, so we can do deferred write at irq
  handling time.
- Display of /proc/irq/XX/smp_affinity used to display CPU_MASKALL, instead
  it now shows only active cpu masks, or exactly what was set.
- Provided a common move_irq implementation, instead of duplicating
  when using generic irq framework.

Tested on i386/x86_64 and ia64 with CONFIG_PCI_MSI turned on and off.
Tested UP builds as well.

MSI testing: tbd: I have cards, need to look for a x-over cable, although I
did test an earlier version of this patch.  Will test in a couple days.
Signed-off-by: NAshok Raj <ashok.raj@intel.com>
Acked-by: NZwane Mwaikambo <zwane@holomorphy.com>
Grudgingly-acked-by: NAndi Kleen <ak@muc.de>
Signed-off-by: NCoywolf Qi Hunt <coywolf@lovecn.org>
Signed-off-by: NAshok Raj <ashok.raj@intel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      54d5d424
  47. 05 9月, 2005 1 次提交