kernel.git/arch/x86/kernel/head64.c, branch linux-2.6.28.y

x86: fix incorrect __read_mostly on _boot_cpu_pda

2009-01-18T18:43:46Z

commit 26799a63110dcbe81291ea53178f6b4810d07424 upstream. The pda rework (commit 3461b0af025251bbc6b3d56c821c6ac2de6f7209) to remove static boot cpu pdas introduced a performance bug. _boot_cpu_pda is the actual pda used by the boot cpu and is definitely not "__read_mostly" and ended up polluting the read mostly section with writes. This bug caused regression of about 8-10% on certain syscall intensive workloads. Signed-off-by: Ravikiran Thirumalai Acked-by: Mike Travis Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

x86_64: be less annoying on boot, v2

2008-09-29T08:04:53Z

Honour "quiet" boot parameter in early_printk() calls Signed-off-by: Diego Calleja Signed-off-by: Ingo Molnar

x86_64: be less annoying on boot

2008-09-25T09:15:20Z

Remove mostly useless message on every boot. Signed-off-by: Bill Nottingham Signed-off-by: Ingo Molnar

x86-64: fix overlap of modules and fixmap areas

2008-08-15T15:31:50Z

Plus add a build time check so this doesn't go unnoticed again. Signed-off-by: Jan Beulich Signed-off-by: Ingo Molnar

x86_64: add workaround for no %gs-based percpu

2008-07-16T08:58:13Z

As a stopgap until Mike Travis's x86-64 gs-based percpu patches are ready, provide workaround functions for x86_read/write_percpu for Xen's use. Specifically, this means that we can't really make use of vcpu placement, because we can't use a single gs-based memory access to get to vcpu fields. So disable all that for now. Signed-off-by: Jeremy Fitzhardinge Cc: Stephen Tweedie Cc: Eduardo Habkost Cc: Mark McLoughlin Signed-off-by: Ingo Molnar

x86: move reserve_setup_data to setup.c

2008-07-08T11:16:14Z

Ying Huang would like setup_data to be reserved, but not included in the no save range. Here we try to modify the e820 table to reserve that range early. also add that in early_res in case bootloader messes up with the ramdisk. other solution would be 1. add early_res_to_highmem... 2. early_res_to_e820... but they could reserve another type memory wrongly, if early_res has some resource reserved early, and not needed later, but it is not removed from early_res in time. Like the RAMDISK (already handled). Signed-off-by: Yinghai Lu Cc: andi@firstfloor.org Tested-by: Huang, Ying Signed-off-by: Ingo Molnar

x86, 64-bit: split x86_64_start_kernel

2008-07-08T11:11:06Z

Split x86_64_start_kernel() into two pieces: The first essentially cleans up after head_64.S. It clears the bss, zaps low identity mappings, sets up some early exception handlers. The second part preserves the boot data, reserves the kernel's text/data/bss, pagetables and ramdisk, and then starts the kernel proper. This split is so that Xen can call the second part to do the set up it needs done. It doesn't need any of the first part setups, because it doesn't boot via head_64.S, and its redundant or actively damaging. Signed-off-by: Jeremy Fitzhardinge Cc: xen-devel Cc: Stephen Tweedie Cc: Eduardo Habkost Cc: Mark McLoughlin Signed-off-by: Ingo Molnar

Merge branch 'x86/numa' into x86/devel

2008-07-08T09:59:23Z

Conflicts: arch/x86/Kconfig arch/x86/kernel/e820.c arch/x86/kernel/efi_64.c arch/x86/kernel/mpparse.c arch/x86/kernel/setup.c arch/x86/kernel/setup_32.c arch/x86/mm/init_64.c include/asm-x86/proto.h Signed-off-by: Ingo Molnar

x86: leave initial __cpu_pda array in place until cpus are booted

2008-07-08T09:31:26Z

Ingo Molnar wrote: ... > they crashed after about 3 randconfig iterations with: > > early res: 4 [8000-afff] PGTABLE > early res: 5 [b000-b87f] MEMNODEMAP > PANIC: early exception 0e rip 10:ffffffff8077a150 error 2 cr2 37 > Pid: 0, comm: swapper Not tainted 2.6.25-sched-devel.git-x86-latest.git #14 > > Call Trace: > [] early_idt_handler+0x56/0x6a > [] ? numa_set_node+0x30/0x60 > [] ? numa_set_node+0x9/0x60 > [] numa_init_array+0x93/0xf0 > [] acpi_scan_nodes+0x3b9/0x3f0 > [] numa_initmem_init+0x136/0x150 > [] setup_arch+0x48f/0x700 > [] ? clockevents_register_notifier+0x3a/0x50 > [] start_kernel+0xd7/0x440 > [] x86_64_start_kernel+0x222/0x280 ... Here's the fixup... This one should follow the previous patches. Thanks, Mike Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner

x86: remove static boot_cpu_pda array v2

2008-07-08T09:31:25Z

* Remove the boot_cpu_pda array and pointer table from the data section. Allocate the pointer table and array during init. do_boot_cpu() will reallocate the pda in node local memory and if the cpu is being brought up before the bootmem array is released (after_bootmem = 0), then it will free the initial pda. This will happen for all cpus present at system startup. This removes 512k + 32k bytes from the data section. For inclusion into sched-devel/latest tree. Based on: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git + sched-devel/latest .../mingo/linux-2.6-sched-devel.git Signed-off-by: Mike Travis Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner