linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [v2.6.26] what's brewing in x86.git for v2.6.26
@ 2008-04-16 20:23 Ingo Molnar
  2008-04-16 20:37 ` Roland Dreier
                   ` (4 more replies)
  0 siblings, 5 replies; 71+ messages in thread
From: Ingo Molnar @ 2008-04-16 20:23 UTC (permalink / raw)
  To: linux-kernel

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit, Size: 51146 bytes --]


what's brewing in x86.git for v2.6.26?

too many topics to list them all - there are 884 patches from 74 authors 
at the moment.

a few highlights:

 - 4096 CPUs support. (Yes, such big boxes exist, and they run Linux.)

 - mmiotrace feature: trace accesses to hw components to help figure out 
   how they are programmed.

 - kmemcheck feature: Valgrind for the native Linux kernel in essence - 
   detects access to uninitialized memory.

 - ftrace plugin for sysprof

 - fixed StackProtector security feature (these fixes were too intrusive 
   for v2.6.25)

 - lazy FPU allocation/speedup - offloaded/large FPU/SSE state support

 - SMP-boot, mpparse, DMA ops unification

 - PAT support - first step towards phasing out MTRR's for cache 
   attribute control

 - enable GBPAGES - faster TLB misses on CPUs that support it

 - debug helper: view kernel pagetable layout via debugfs

 - lots of paravirt work, unification and cleanups

 - generalized bitops - they are faster and smaller.

 - tons of code cleanups either via the unifications or via explicit 
   cleanup patches - the metrics [via checkpatch] look like this today:

                                         errors   lines of code   errors/KLOC
 [pre-unification:]
 v2.6.23          arch/i386/               5954           83593          71.2
 v2.6.23          arch/x86_64/             2899           31830          91.0

 [mechanic unification:]
 v2.6.24-rc1      arch/x86/                8695          117423          74.0

 [post-unification cleanup work-in-progress:]
 v2.6.24-x86.git  arch/x86/ [21 Nov 2007]  5190          117156          44.2
 v2.6.24-x86.git  arch/x86/ [18 Dec 2007]  4057          117213          34.6
 v2.6.24-x86.git  arch/x86/ [ 4 Feb 2008]  3334          133542          24.9
 v2.6.25-x86.git  arch/x86/ [21 Feb 2008]  2724          136963          19.8
 v2.6.25-x86.git  arch/x86/ [ 1 Mar 2008]  2155          136404          15.7
 v2.6.25-x86.git  arch/x86/ [ 7 Apr 2008]  1868          136793          13.6

 - lots of enhancements for large and small systems alike.

 - ... and more.

See the shortlog below for details. The git tree can be fetched via:

  http://people.redhat.com/mingo/x86.git/README

	Ingo

------------------>
Adrian Bunk (1):
      x86: remove the write-only timer_uses_ioapic_pin_0

Akinobu Mita (6):
      x86: avoid redundant loop in io_apic_level_ack_pending()
      x86: use ioapic_read_entry() and ioapic_write_entry()
      x86: remove unnecessary memset()
      x86: remove unnecessary tmp local variable
      x86: use cpumask_of_cpu()
      x86: use cpu_online()

Alan Mayer (1):
      x86: resize NR_IRQS for large machines

Alexander van Heukelum (24):
      x86: reserve end-of-conventional-memory to 1MB on 32-bit
      x86: reserve_early end-of-conventional-memory to 1MB, 64-bit
      x86: reserve end-of-conventional-memory to 1MB, 64-bit
      x86: reserve end-of-conventional-memory to 1MB, 32-bit, use paravirt_enabled
      x86: reserve end-of-conventional-memory to 1MB, 64-bit, use paravirt_enabled
      x86: remove superfluous initialisation in boot code.
      x86: cleanup boot-heap usage
      x86: change x86 to use generic find_next_bit
      x86: fix uml with generic find_next_bit for x86
      x86, generic: optimize find_next_(zero_)bit for small constant-size bitmaps
      x86: merge the simple bitops and move them to bitops.h
      x86: K8, GEODE_LX, CRUSOE, EFFICEON and CORE2 support the cmovxx instructions.
      generic: introduce a generic __fls implementation
      generic: implement __fls on all 64-bit archs
      Use __fls for fls64 on 64-bit archs
      x86: generic versions of find_first_(zero_)bit, convert i386
      x86: switch x86_64 to generic find_first_bit
      x86: optimize find_first_bit for small bitmaps
      x86: remove x86-specific implementations of find_first_bit
      x86: finalize bitops unification
      Build fix for uml/i386
      Build fix for uml/x86_64
      uml: cleanup: use def_bool in Kconfig files
      powerpc: fix find_next_bit breakage on ppc and powerpc

Alexey Dobriyan (1):
      arch/x86/: switch to proc_create()

Alexey Starikovskiy (72):
      x86: move quad_local_to_mp_bus_id to numa.c
      x86: add mp_bus_not_pci bitmap to mpparse_32.c
      x86: use not_pci bitmap #1
      x86: use not_pci bitmap #2
      x86: use not_pci bitmap #3
      x86: use not_pci bitmap #4
      x86: use not_pci bitmap #5
      x86: use not_pci bitmap #6
      x86: rearrange bus_type parse
      x86: make mp_bus_id_to_type optional
      x86: move mp_bus_id_to_local to numa.c
      Move mp_bus_id_to_node to numa.c
      x86: lindent mpparse_64.c
      x86: add bad_ioapic to mpparse_32.c
      x86: add uniq_ioapic_id to mpparse_32.c
      x86: use get_bios_ebda in mpparse_64.c
      x86: limit scan to 1k of EBDA.
      x86: rename gsi_start to gsi_base to match mpparse_32.c
      x86: remove mpc_apic_id()
      x86: remove mpc_oem_pci_bus()
      x86: remove mpc_oem_bus_info()
      x86: make struct mpc_config_translation NUMAQ-only
      x86: use same index for processor maps
      x86: move es7000_plat closer to its user
      x86: don't call MP_processor_info for disabled cpu
      x86: separate generic_processor_info into its own function
      x86: don't use MP_processor_info for ACPI mode
      x86: move apic_ver array to apic_32.c
      x86: move mp_lapic_addr to apic_32.c
      x86: move phys_cpu_present_map to smpboot.c
      x86: move num_processors to smpboot.c
      x86: move disabled_cpus to smpboot.c
      x86: move def_to_bigsmp to setup_32.c
      x86: move boot_cpu_physical_apicid to apic_32.c
      x86: move x86_bios_cpu_apicid to apic_32.c
      x86: move generic_processor_info to apic_32.c
      x86: don't call MP_processor_info for disabled cpu (64bit)
      x86: separate generic_processor_info into its own function (64bit)
      x86: don't use MP_processor_info for ACPI mode (64bit)
      x86: move mp_lapic_addr to apic_64.c
      x86: move phys_cpu_present_map to smpboot.c (64bit)
      x86: move num_processors to smpboot.c (64 bit)
      x86: move disabled_cpus to smpboot.c (64bit)
      x86: move boot_cpu_physical_apicid to apic_64.c
      x86: move generic_processor_info to apic_64.c
      x86: move x86_bios_cpu_apicid to io_apic_64.c
      x86: move x86_cpu_to_apicid to setup.c
      x86: move phys_cpu_present_map to setup.c
      x86: move x86_cpu_to_apicid_init to smpboot.c
      x86: move x86_bios_cpu_apicid_init to smpboot.c
      x86: Don't set IO APIC features if IO APIC is not enabled
      x86: move mp_ioapics to io_apic_32.c
      x86: move mp_ioapics to io_apic_64.c
      x86: move mp_ioapic_routing to boot.c
      x86: move mp_irqs to io_apics_32.c
      x86: move mp_irqs to io_apic_64.c
      x86: move up & smp variables to setup.c
      x86: move mp_register_lapic to boot.c
      x86: move mp_register_lapic_address to boot.c
      x86: Lindend mpparse_32.c
      x86: add early flags to mpparse_32.c
      x86: unify arch/x86/kernel/mpparse_64.c
      x86: unify mp_bus_info
      x86: unify smp_read_mpc
      x86: unify construct_default_ioirq_mptable
      x86: unify get_smp_config
      x86: unify smp_scan_config
      x86: unify uniq_io_apic_id
      x86: unify mp_register_ioapic
      x86: unify mp_config_acpi_legacy_irqs
      x86: unify mp_register_gsi
      x86: merge mpparse_{32,64}.c

Alok Kataria (1):
      x86: fix paranoia about using BIOS quickboot mechanism.

Andi Kleen (13):
      x86: do kernel direct mapping at boot using GB pages
      x86: use year 2000 offset for cmos clock
      x86: add warning when RTC clock reports binary
      x86: enable ACPI extended century handling for 32bit
      x86: don't set up early exception handlers for external interrupts
      x86: replace early exception setup macro recursion with loop
      x86: move early exception handlers into init.text
      x86: implement true end_pfn_mapped for 32bit
      x86: account overlapped mappings in max_pfn_mapped
      x86: add set_memory_4k to pageattr.c
      x86: don't use large pages to map the first 2/4MB of memory
      x86: re-add rdmsrl_safe
      x86: split large page mapping for AMD TSEG

Andres Salomon (1):
      x86: geode: MSR cleanup

Andrew Morton (2):
      i386: arch/x86/math-emu/fpu_entry.c warning fix
      i386: arch/x86/math-emu/reg_ld_str.c: fix warning

Arjan van de Ven (6):
      x86: add code to dump the (kernel) page tables for visual inspection by kernel developers
      x86: setup stack canary for the idle threads
      x86: introduce /dev/mem restrictions with a config option
      x86: add CONFIG_CC_STACKPROTECTOR selftest
      x86: mark init_mm deprecated
      x86: add comments to describe the new api's in cacheflush.h

Arnaldo Carvalho de Melo (1):
      x86: reducing debuginfo size by removing unneeded includes

Auke Kok (1):
      e1000e: set CONFIG_E1000E=y in x86 defconfigs

Ben Castricum (1):
      x86: microcode: show results on success too

Björn Steinbrink (1):
      x86, pci: fix off-by-one errors in some pirq warnings

Christian Limpach (1):
      xen blkfront: Delay wait for block devices until after the disk is added

Cyrill Gorcunov (4):
      x86: processor.h - use PAGE_SIZE instead of numeric value
      x86: relocate_kernel - use predefined PAGE_SIZE instead of own alias
      x86: entry_32.S - use flags from processor-flags.h
      x86: debug Store - call kfree if only we really need it

Dave Jones (1):
      x86: Centaur Isaiah processor to use sysenter in 64-bit compatibility mode rather than syscall

David P. Reed (3):
      x86: fix cmos read and write to not use inb_p and outb_p
      x86: define outb_pic and inb_pic to stop using outb_p and inb_p
      x86: use explicit timing delay for pit accesses in kernel and pcspkr driver

Eric Dumazet (1):
      percpu: introduce DEFINE_PER_CPU_PAGE_ALIGNED() macro

Eric W. Biederman (1):
      x86: introduce kernel/head32.c

Erik Bosman (3):
      generic, x86: add prctl commands PR_GET_TSC and PR_SET_TSC
      x86: implement prctl PR_GET_TSC and PR_SET_TSC
      generic, x86: add tests for prctl PR_GET_TSC and PR_SET_TSC

Florian Fainelli (1):
      x86, rdc321x: remove watchdog file

Gautham R Shenoy (1):
      x86: Don't send RESCHEDULE_VECTOR to offlined cpus

Glauber Costa (110):
      x86: change vsmp compile dependency
      x86: make vsmp_init void, instead of static int
      x86: call vsmp_init explicitly
      introduce paravirt helpers
      use the paravirt helpers
      x86: commonize smp.h
      x86: merge extern function definitions
      x86: merge extern variables definitions
      x86: define smp_ops in common header
      x86: move smp_ops extern declaration to common header
      x86: merge smp_send_reschedule
      x86: unify smp_call_function_mask
      x86: unify __cpu_up.
      x86: unify prepare_boot_cpu
      x86: unify smp_prepare_cpus
      x86: unify smp_cpus_done
      x86: move disabled_cpus to common header
      x86: use disabled_cpus in i386
      x86: move prefill_possible_map to common file
      x86: remove export for smp_call_function_mask.
      x86: remove irqs disabled warning.
      x86: create smpcommon.c
      x86: provide __smp_call_function
      x86: change x86_64 smp_call_function_mask to look alike i386
      x86: provide hlt_works function.
      x86: make stop_this_cpu looks exactly equal in both arches
      x86: add reboot_force test to native_smp_send_stop
      x86: unify smp_send_stop
      x86: create smp.c
      x86: create ipi.c
      x86: create tlb files
      x86: get rid of smp_32.c and smp_64.c
      x86: remove cpu_llc_id from processor.h
      x86: adjust types in smpcommon_32.c
      x86: move equal types to common file
      x86: make set_cpu_sibling_map nonstatic
      x86: make remove_siblinginfo non-static
      x86: move hotplug related extern definitions to smp.h
      x86: move sibling functions to common file
      x86: move cpu_coregroup_map to common file
      x86: remove vector_lock around cpu_online_map
      x86: use remove_from_maps in cpu_disable
      x86: do not clear cpu_online_map
      x86: merge __cpu_disable and cpu_die
      x86: make x86_64 accept the max_cpus parameter
      x86: move trampoline arrays extern definition to smp.h
      x86: adapt voyager's trampoline_base
      x86: adapt voyager's setup_trampoline
      x86: unify setup_trampoline
      x86: use wait_for_init_deassert in x86_64
      x86: use cpu_relax instead of rep_nop
      x86: move ipi definitions to mach_ipi.h
      move apic declarations to mach_apic.h
      x86: surround hard_smp_processor_id in APIC_DEFINITION
      x86: provide bogus hard_smp_processor_id
      x86: merge hard/logical_smp_processor_id
      x86: surround apic headers in apic definitions
      x86: merge includes in smp.h
      x86: split safe_smp_processor_id
      x86: merge SMP definitions of smp.h
      x86: change naming of cpu_initialized_mask for xen
      x86: merge smp_32.h and smp_64.h into smp.h
      x86: move dma_ops struct definition to dma-mapping.h
      x86: implement dma_map_single through dma_ops
      x86: move dma_unmap_single to common header
      x86: move dma_map_sg to common header
      x86: move dma_unmap_sg to common header
      x86: move dma_sync_single_for_cpu to common header
      x86: move dma_sync_single_for_device to common header
      x86: move dma_sync_single_range_for_cpu to common header
      x86: move dma_sync_single_range_for_device to common header
      x86: move dma_sync_sg_for_cpu to common header
      x86: move dma_sync_sg_for_device to common header
      x86: move alloc and free coherent to common header
      x86: move dma_map_page and dma_unmap_page to common header
      x86: move dma_cache_sync to common header
      x86: move dma_supported and dma_set_mask to pci-dma_32.c
      x86: align to clflush size
      x86: provide a bad_dma_address symbol for i386
      x86: unify dma_mapping_error
      x86: move ARCH_HAS_DMA_DECLARE_COHERENT_MEMORY to dma-mapping.h
      x86: delete the arch-specific dma-mapping headers.
      x86: introduce pci-dma.c
      x86: delete empty functions from pci-nommu_64.c
      x86: implement mapping_error in pci-nommu_64.c
      x86: Add flush_write_buffers in nommu functions
      x86: use sg_phys in x86_64
      x86: use WARN_ON in mapping functions
      x86: use dma_length in i386
      x86: move definition to pci-dma.c
      x86: unify pci-nommu
      x86: move initialization functions to pci-dma.c
      x86: move x86_64-specific to common code.
      x86: move pci fixup to pci-dma.c
      x86: merge dma_supported
      x86: merge iommu initialization parameters
      x86: move dma_coherent functions to pci-dma.c
      x86: isolate coherent mapping functions
      x86: move bad_dma_address
      x86: adjust dma_free_coherent for i386
      x86: remove virt_to_bus in pci-dma_64.c
      x86: use numa allocation function in i386
      x86: use a fallback dev for i386
      x86: don't try to allocate from DMA zone at first
      x86: retry allocation if failed
      x86: unify gfp masks
      x86: remove kludge from x86_64
      x86: return conditional to mmu
      x86: don't do dma if mask is NULL.
      x86: integrate pci-dma.c

Glauber de Oliveira Costa (78):
      x86: change var types in __inquire_remote_apic
      x86: add loglevel to printks
      x86: use apic_*_around instead of apic_write in x86_64
      x86: use start_ipi_hook in x86_64
      x86: add an smp_apply_quirks to smpboot_32.c
      x86: decouple call to print_cpu_info from smp_store_cpu_info
      x86: provide specialized identification routines for x86_64
      x86: use identify_boot_cpu
      x86: call identify_secondary_cpu in smp_store_cpu_info
      x86: merge smp_store_cpu_info
      x86: always enable irqs when entering idle
      x86: don't call local_irq_enable before entering idle
      x86: move setup_secondary_clock a little bit down in the function
      x86: move state update out of ipi_lock
      x86: provide APIC_INTEGRATED definition for x86_64
      x86: use APIC_INTEGRATED tests in x86_64
      x86: add barriers statement
      x86: isolate sanity checking
      x86: isolate logic to disable smp
      x86: do tests before do_boot_cpu in i386
      x86: make __smp_prepare_cpu void
      x86: move assignment of CPU_PREPARE before do_boot_cpu
      x86: unify extern masks declaration
      x86: define bios to apicid mapping
      x86: initialize map pointers in setup_32.c
      x86: make node to apic mapping declarations unconditional
      x86: fix alloc_bootmem_pages_node macro
      x86: use specialized routine for setup per-cpu area
      x86: fill bios cpu to apicid maps
      x86: fill cpu to apicid and present map in mpparse
      x86: get rid of cpucount
      x86: allow user to impress friends.
      x86: do smp tainting checks in a separate function
      x86: move impress_friends and smp_check to cpus_done
      x86: add subarch support (for headers) to x86_64
      x86: include mach_wakecpu.h in smpboot_64
      x86: include smpboot_hooks.h in smpboot_64.c
      x86: move smp_intr_init away from smpboot_32.c
      x86: don't set maps in native_smp_prepare_boot_cpu()
      x86: wipe get_nmi_reason out of nmi_64.h
      x86: unify nmi_32.h and nmi_64.h
      x86: call check_nmi_watchdog explicitly in native_smp_cpus_done
      x86: call nmi_watchdog_default in i386
      x86: don't initialize sibling and core maps during preparation
      x86: schedule work only if keventd is already running
      x86: do not zap_low_mappings in __smp_prepare_cpus
      x86: boot cpus from cpu_up, instead of prepare_cpus
      x86: get rid of commenced mask.
      x86: use create_idle struct in do_boot_cpu
      x86: don't span a new worker in __smp_prepare_cpu
      x86: modify smp_callin in x86_64 to look like i386
      x86: wrap esr setting up in i386 in lapic_setup_esr
      x86: provide an end_local_APIC_setup function
      x86: calibrate delay with irqs enabled
      x86: minor adjustments for do_boot_cpu
      x86: call do_boot_cpu directly from native_cpu_up
      x86: include mach_apic.h in smpboot_64.c and smpboot.c
      x86: change wakeup_secondary name
      x86: add callin tests to cpu_up
      x86: move {un}map_cpu_to_logical_apicid to smpboot.c
      x86: move stack_start to smp.h
      x86: change boot_cpu_id to boot_cpu_physical_apicid
      x86: integrate do_boot_cpu
      x86: integrate start_secondary
      x86: merge smp_prepare_boot_cpu
      x86: merge native_smp_cpus_done
      x86: use physical id when disabling smp
      x86: get rid of smp_boot_cpus
      x86: additions to i386 native_smp_prepare_cpus.
      x86: assign nr_ioapics = 0 in smpboot_hooks.h
      x86: change x86_64 native_smp_prepare_cpus to match i386
      x86: add extra sanity check
      x86: change x86_64 sanity checks to match i386.
      x86: introduce smpboot_clear_io_apic
      x86: merge native_smp_prepare_cpus
      x86: merge cpu_exit_clear
      x86: move apicid mappings to smpboot.c
      x86: remove smpboot_32.c and smpboot_64.c

H. Peter Anvin (2):
      x86: unify arch/x86/mm/Makefile
      x86: clean up the page table dumper and add 32-bit support

Harvey Harrison (11):
      x86: change most X86_32 pt_regs members to unsigned long
      x86: make X86_32 pt_regs members unsigned long
      x86: regparm(3) is mandatory, no need to annotate
      x86: reduce trivial style differences in signal_32|64.c
      x86: Use FIX_EFLAGS define in X86_64
      x86: use sizeof(long) to unify signal_32|64.c
      x86: move struct definitions to unifed sigframe.h
      x86: Unify argument names in signal_32|64.c
      x86: define DEBUG_SIG in signal_64.c
      x86: replace remaining __FUNCTION__ occurances
      x86: pageattr.c fix shadowed variable warning

Hiroshi Shimamoto (6):
      x86: split cpuinfo from setup_64.c into cpu/proc_64.c
      x86: make cpu/proc|_64.c similar
      x86: add power management line in /proc/cpuinfo
      x86: cosmetic unification cpu/proc|_64.c
      x86: unify cpu/proc|_64.c
      x86: X86_HT always enable on X86_64 SMP

Huang, Ying (5):
      x86: EFI_PAGE_SHIFT fix
      x86, boot: add free_early to early reservation machanism
      x86, boot: add linked list of struct setup_data
      x86, boot: export linked list of struct setup_data via debugfs
      x86, boot: Document for linked list of struct setup_data

Hugh Dickins (1):
      x86: MPSC should use P6 NOPs

Ian Campbell (4):
      x86: use ELF format in compressed images.
      x86: add a crc32 checksum to the kernel image.
      x86: reduce arch/x86/mm/ioremap.o size
      x86: boot protocol updates

Ingo Molnar (85):
      x86: check vmlinux limits, 64-bit
      x86: increase the kernel text limit to 512 MB
      x86: fix the pagetable dumper
      x86: add gbpages switches
      x86: bump image header to version 2.08.
      x86: clean up mmx_32.c
      x86: more coding style fixes in centaur.c
      x86: clean up include/asm-x86/processor.h
      x86: more cleanups in arch/x86/boot/compressed/misc.c
      x86: de-macro start_thread()
      x86: clean up cpu capabilities accesses
      x86: clean up cpu capabilities accesses, generic
      x86: clean up cpu capabilities accesses, amd.c
      x86: clean up cpu capabilities accesses, centaur.c
      x86: clean up cpu capabilities accesses, common.c
      x86: clean up cpu capabilities accesses, cyrix.c
      x86: clean-up-cpu-capabilities-intel.c.patch
      x86: clean up cpu capabilities accesses, transmeta.c
      x86: clean up traps_32.c
      x86, tracing: add notrace to asm-x86/linkage.h
      x86: ioremap(), extend check to all RAM pages
      x86: patches/lguest-fix4.patch
      x86: warn about RAM pages in ioremap()
      x86: redo cded932b75ab0a5f9181e
      x86: debug pmd_bad()
      x86: stackprotector & PARAVIRT fix
      x86: fix stackprotector canary updates during context switches
      x86: fix canary of the boot CPU's idle task
      panic: print more informative messages on stackprotect failure
      panic: print out stacktrace if DEBUG_BUGVERBOSE
      x86: enable stack-protector by default
      stackprotector: include files
      stackprotector: add boot_init_stack_canary()
      x86: fix the stackprotector canary of the boot CPU
      x86: stackprotector: mix TSC to the boot canary
      x86: unify stackprotector features
      x86: clean up switch_to()
      x86: fix switch_to() clobbers
      x86: add comments to processor.h
      x86: clean up i387.c
      x86: remove DEBUG_SIG
      x86: clean up arch/x86/kernel/signal_32.c
      x86: move extern declaration to vdso.h
      x86: add KERN_INFO to show_unhandled_signals printout
      x86: remove mach_reboot.h
      x86: fill cpu to apicid and present map in mpparse, fix
      x86: vsmp fix x86 vsmp fix is vsmp box cleanup
      debugging: always enable stacktrace
      x86: revert ucminus change
      x86: fix ioapic bug again
      x86: PAT fix
      undo "x86: fix breakage of vSMP irq operations"
      x86: tom2 warning fix
      x86: spinlock ops are always-inlined
      x86: ioremap of 64-bit resource on 32-bit kernel fix
      unify: mpparse2 move disabled cpus to smpboot c fix
      unify: mpparse2 move boot cpu physical apicid to apic 32 c fix
      unify: mpparse2 move generic processor info to apic 32 c fix
      unify: move phys cpu present map to smpboot.c, 64bit, prepare
      x86: mpparse: 64-bit fix
      x86: cleanup replace most vm86 flags with flags from processor-flags.h, fix
      x86: support for new UV apic, prepare
      x86: uv fix
      x86: set_cyc2ns_scale() remove prev scale
      x86: improve default idle
      pat: cleanup
      x86: extend the scheduled bzImage symlinks removal
      x86: 4kstacks default
      unify: mpparse4 x86 don t set io apic features if io apic is not enabled fix
      x86: add optimized inlining
      generic: optimized inlining, fix
      x86: clean up cpu capabilities accesses, p4-clockmod.c
      nohz: fix typo in tick-broadcast.c
      kgdb: light v16
      kgdb: IPI fixup
      x86: fix k8-bus_64.c build
      x86: sanity check gart for buggy device, fix
      x86: xen unify x86 add common mm pgtable c fix
      x86: dma-ops on highmem fix
      kmemcheck: fix-up (some bogus) reports
      x86: kmemcheck v7 fix
      kmemcheck: config
      x86: add x86-latest.git tag
      x86: standalone trampoline code
      x86: rename find_max_pfn() to propagate_e820_map()

Isaku Yamahata (12):
      xen: definisions which ia64 needs
      xen: definitions which ia64/xen needs
      xen: add missing definitions for xen grant table which ia64/xen needs
      xen: add missing definitions in include/xen/interface/vcpu.h which ia64/xen needs
      xen: move features.c from arch/x86/xen/features.c to drivers/xen
      xen: move events.c to drivers/xen for IA64/Xen support
      Xen: make events.c portable for ia64/xen support
      xen: add resend_irq_on_evtchn() definition into events.c
      xen: make include/xen/page.h portable moving those definitions under asm dir
      xen: replace callers of alloc_vm_area()/free_vm_area() with xen_ prefixed one
      xen: make grant table arch portable
      xen: import arch generic part of xencomm

Jacek Luczak (10):
      x86: remove vm86.h inclusion from process_32.c
      x86: e820_64, fix section mismatch warning
      x86: section mismatch fixes, #1
      x86: setup_trampoline() - fix section mismatch warning
      x86: section mismatch fixes, #2
      x86: section mismatch fixes, #3
      x86: trampoline_32.S - switch to .cpuinit.data
      x86: uniq_ioapic_id - fix section mismatch warning
      x86: unlock_ExtINT_logic() - fix section mismatch warnings
      x86: pgtable_32.h - prototype and section mismatch fixes

Jack Steiner (11):
      x86: increase max physical memory size of 64-bit
      x86: allow NODES_SHIFT to be a config option on x86_64
      x86: change GET_APIC_ID() from an inline function to an out-of-line function
      x86: add functions to determine if platform is a UV platform
      x86: increase size of APICID
      x86: parsing for ACPI "SAPIC" table
      x86: add UV specific header for MMR definitions
      x86: define the macros and tables for the basic UV infrastructure.
      x86: define the macros and tables for blade functions
      x86: support for new UV apic
      x86: support for new UV apic, fix

Jan Beulich (3):
      x86: prevent unconditional writes to DebugCtl MSR
      x86: simplify sync_test_bit()
      x86: bitops asm constraint fixes

Jeremy Fitzhardinge (39):
      xen: use iret instruction all the time
      x86: only enable interrupts when kernel state has been set up
      x86: simplify sync_test_bit(), improve
      x86: sparsemem: reduce i386 PAE section size
      x86: paravirt_ops: don't steal memory resources in paravirt_disable_iospace
      x86: convert pgalloc_64.h from macros to inlines
      x86: add common mm/pgtable.c
      x86: put paravirt stubs into common asm/pgalloc.h
      x86: move pte functions into common asm/pgalloc.h
      x86: move pmd functions into common asm/pgalloc.h
      x86: move pgalloc pud and pgd operations into common place
      x86: move all the pgd_list handling to one place
      x86: rename paravirt_alloc_pt etc after the pagetable structure
      x86: add pud_alloc for 4-level pagetables
      x86/pgtable.h: demacro ptep_set_access_flags
      x86/pgtable.h: demacro ptep_test_and_clear_young
      x86/pgtable.h: demacro ptep_clear_flush_young
      x86: demacro pgalloc paravirt stubs
      xen: use appropriate pte types
      xen: make use of pte_t union
      xen: unify pte operations
      xen: use phys_addr_t when referring to physical addresses
      xen: unify pte operations on machine frames
      xen: make sure iret faults are trapped
      x86: unify KERNEL_PGD_PTRS
      x86: unify pgd ctor/dtor
      xen: add support for callbackops hypercall
      xen: support sysenter/sysexit if hypervisor does
      xen: implement a debug-interrupt handler
      xen: make sure retriggered events are set pending
      xen: short-cut for recursive event handling
      xen: no need for domU to worry about MCE/MCA
      xen: jump to iret fixup
      xen/blkfront: use bdget_disk
      xen: disable preemption during tlb flush
      xen: allow set_pte_at on init_mm to be lockless
      xen: fold xen_sysexit into xen_iret
      xen: allow compilation with non-flat memory
      xen: add balloon driver

Jesper Juhl (1):
      x86 floppy: kill off the 'register' keyword from header

Jiri Slaby (3):
      x86: pgtable, document pde bits
      x86: fix exec mappings comments
      x86, generic: mark early_printk as asmlinkage

Joe Perches (146):
      x86: include/asm-x86/mutex_32.h - use angle brackets for include
      x86: arch/x86/kernel/cpu/feature_names.c - use angle brackets for include
      x86 - cleanup duplicate includes
      include/asm-x86/acpi.h: checkpatch cleanups - formatting only
      include/asm-x86/alternative.h: checkpatch cleanups - formatting only
      include/asm-x86/a.out-core.h: checkpatch cleanups - formatting only
      include/asm-x86/apicdef.h: checkpatch cleanups - formatting only
      include/asm-x86/apic.h: checkpatch cleanups - formatting only
      include/asm-x86/atomic_32.h: checkpatch cleanups - formatting only
      include/asm-x86/atomic_64.h: checkpatch cleanups - formatting only
      include/asm-x86/bitops_32.h: checkpatch cleanups - formatting only
      include/asm-x86/bitops_64.h: checkpatch cleanups - formatting only
      include/asm-x86/bitops.h: checkpatch cleanups - formatting only
      include/asm-x86/bug.h: checkpatch cleanups - formatting only
      include/asm-x86/byteorder.h: checkpatch cleanups - formatting only
      include/asm-x86/cacheflush.h: checkpatch cleanups - formatting only
      include/asm-x86/checksum_32.h: checkpatch cleanups - formatting only
      include/asm-x86/checksum_64.h: checkpatch cleanups - formatting only
      include/asm-x86/cmpxchg_32.h: checkpatch cleanups - formatting only
      include/asm-x86/cmpxchg_64.h: checkpatch cleanups - formatting only
      include/asm-x86/compat.h: checkpatch cleanups - formatting only
      include/asm-x86/current_32.h: checkpatch cleanups - formatting only
      include/asm-x86/current_64.h: checkpatch cleanups - formatting only
      include/asm-x86/desc_defs.h: checkpatch cleanups - formatting only
      include/asm-x86/desc.h: checkpatch cleanups - formatting only
      include/asm-x86/div64.h: checkpatch cleanups - formatting only
      include/asm-x86/dma.h: checkpatch cleanups - formatting only
      include/asm-x86/dwarf2_64.h: checkpatch cleanups - formatting only
      include/asm-x86/e820_32.h: checkpatch cleanups - formatting only
      include/asm-x86/e820_64.h: checkpatch cleanups - formatting only
      include/asm-x86/edac.h: checkpatch cleanups - formatting only
      include/asm-x86/efi.h: checkpatch cleanups - formatting only
      include/asm-x86/elf.h: checkpatch cleanups - formatting only
      include/asm-x86/fixmap_32.h: checkpatch cleanups - formatting only
      include/asm-x86/fixmap_64.h: checkpatch cleanups - formatting only
      include/asm-x86/floppy.h: checkpatch cleanups - formatting only
      include/asm-x86/futex.h: checkpatch cleanups - formatting only
      include/asm-x86/genapic_32.h: checkpatch cleanups - formatting only
      include/asm-x86/geode.h: checkpatch cleanups - formatting only
      include/asm-x86/highmem.h: checkpatch cleanups - formatting only
      include/asm-x86/hw_irq_64.h: checkpatch cleanups - formatting only
      include/asm-x86/hypertransport.h: checkpatch cleanups - formatting only
      include/asm-x86/i387.h: checkpatch cleanups - formatting only
      include/asm-x86/i8259.h: checkpatch cleanups - formatting only
      include/asm-x86/ia32.h: checkpatch cleanups - formatting only
      include/asm-x86/io_32.h: checkpatch cleanups - formatting only
      include/asm-x86/io_64.h: checkpatch cleanups - formatting only
      include/asm-x86/ioctls.h: checkpatch cleanups - formatting only
      include/asm-x86/io.h: checkpatch cleanups - formatting only
      include/asm-x86/ipcbuf.h: checkpatch cleanups - formatting only
      include/asm-x86/ipi.h: checkpatch cleanups - formatting only
      include/asm-x86/irq_32.h: checkpatch cleanups - formatting only
      include/asm-x86/irq_64.h: checkpatch cleanups - formatting only
      include/asm-x86/irqflags.h: checkpatch cleanups - formatting only
      include/asm-x86/kdebug.h: checkpatch cleanups - formatting only
      include/asm-x86/kexec.h: checkpatch cleanups - formatting only
      include/asm-x86/kprobes.h: checkpatch cleanups - formatting only
      include/asm-x86/kvm_host.h: checkpatch cleanups - formatting only
      include/asm-x86/kvm_x86_emulate.h: checkpatch cleanups - formatting only
      include/asm-x86/lguest_hcall.h: checkpatch cleanups - formatting only
      include/asm-x86/lguest.h: checkpatch cleanups - formatting only
      include/asm-x86/local.h: checkpatch cleanups - formatting only
      include/asm-x86/mc146818rtc.h: checkpatch cleanups - formatting only
      include/asm-x86/mca_dma.h: checkpatch cleanups - formatting only
      include/asm-x86/mmu_context_32.h: checkpatch cleanups - formatting only
      include/asm-x86/mmu_context_64.h: checkpatch cleanups - formatting only
      include/asm-x86/mmu.h: checkpatch cleanups - formatting only
      include/asm-x86/mmx.h: checkpatch cleanups - formatting only
      include/asm-x86/mmzone_32.h: checkpatch cleanups - formatting only
      include/asm-x86/mmzone_64.h: checkpatch cleanups - formatting only
      include/asm-x86/mpspec_def.h: checkpatch cleanups - formatting only
      include/asm-x86/mpspec.h: checkpatch cleanups - formatting only
      include/asm-x86/msidef.h: checkpatch cleanups - formatting only
      include/asm-x86/msr.h: checkpatch cleanups - formatting only
      include/asm-x86/mtrr.h: checkpatch cleanups - formatting only
      include/asm-x86/mutex_32.h: checkpatch cleanups - formatting only
      include/asm-x86/mutex_64.h: checkpatch cleanups - formatting only
      include/asm-x86/numa_64.h: checkpatch cleanups - formatting only
      include/asm-x86/numaq.h: checkpatch cleanups - formatting only
      include/asm-x86/page_32.h: checkpatch cleanups - formatting only
      include/asm-x86/page_64.h: checkpatch cleanups - formatting only
      include/asm-x86/param.h: checkpatch cleanups - formatting only
      include/asm-x86/paravirt.h: checkpatch cleanups - formatting only
      include/asm-x86/parport.h: checkpatch cleanups - formatting only
      include/asm-x86/pci_64.h: checkpatch cleanups - formatting only
      include/asm-x86/pci-direct.h: checkpatch cleanups - formatting only
      include/asm-x86/pci.h: checkpatch cleanups - formatting only
      include/asm-x86/pda.h: checkpatch cleanups - formatting only
      include/asm-x86/percpu.h: checkpatch cleanups - formatting only
      include/asm-x86/pgtable-2level.h: checkpatch cleanups - formatting only
      include/asm-x86/pgtable_32.h: checkpatch cleanups - formatting only
      include/asm-x86/pgtable-3level.h: checkpatch cleanups - formatting only
      include/asm-x86/pgtable_64.h: checkpatch cleanups - formatting only
      include/asm-x86/pgtable.h: checkpatch cleanups - formatting only
      include/asm-x86/posix_types_32.h: checkpatch cleanups - formatting only
      include/asm-x86/posix_types_64.h: checkpatch cleanups - formatting only
      include/asm-x86/processor.h: checkpatch cleanups - formatting only
      include/asm-x86/proto.h: checkpatch cleanups - formatting only
      include/asm-x86/ptrace.h: checkpatch cleanups - formatting only
      include/asm-x86/reboot.h: checkpatch cleanups - formatting only
      include/asm-x86/resume-trace.h: checkpatch cleanups - formatting only
      include/asm-x86/rio.h: checkpatch cleanups - formatting only
      include/asm-x86/rwsem.h: checkpatch cleanups - formatting only
      include/asm-x86/setup.h: checkpatch cleanups - formatting only
      include/asm-x86/sigcontext32.h: checkpatch cleanups - formatting only
      include/asm-x86/sigcontext.h: checkpatch cleanups - formatting only
      include/asm-x86/signal.h: checkpatch cleanups - formatting only
      include/asm-x86/smp_32.h: checkpatch cleanups - formatting only
      include/asm-x86/smp_64.h: checkpatch cleanups - formatting only
      include/asm-x86/spinlock.h: checkpatch cleanups - formatting only
      include/asm-x86/srat.h: checkpatch cleanups - formatting only
      include/asm-x86/string_32.h: checkpatch cleanups - formatting only
      include/asm-x86/string_64.h: checkpatch cleanups - formatting only
      include/asm-x86/suspend_32.h: checkpatch cleanups - formatting only
      include/asm-x86/suspend_64.h: checkpatch cleanups - formatting only
      include/asm-x86/swiotlb.h: checkpatch cleanups - formatting only
      include/asm-x86/sync_bitops.h: checkpatch cleanups - formatting only
      include/asm-x86/system.h: checkpatch cleanups - formatting only
      include/asm-x86/tce.h: checkpatch cleanups - formatting only
      include/asm-x86/thread_info_32.h: checkpatch cleanups - formatting only
      include/asm-x86/thread_info_64.h: checkpatch cleanups - formatting only
      include/asm-x86/tlbflush.h: checkpatch cleanups - formatting only
      include/asm-x86/topology.h: checkpatch cleanups - formatting only
      include/asm-x86/tsc.h: checkpatch cleanups - formatting only
      include/asm-x86/uaccess_32.h: checkpatch cleanups - formatting only
      include/asm-x86/uaccess_64.h: checkpatch cleanups - formatting only
      include/asm-x86/unaligned.h: checkpatch cleanups - formatting only
      include/asm-x86/unistd_32.h: checkpatch cleanups - formatting only
      include/asm-x86/unistd_64.h: checkpatch cleanups - formatting only
      include/asm-x86/user_32.h: checkpatch cleanups - formatting only
      include/asm-x86/user32.h: checkpatch cleanups - formatting only
      include/asm-x86/user_64.h: checkpatch cleanups - formatting only
      include/asm-x86/vdso.h: checkpatch cleanups - formatting only
      include/asm-x86/vga.h: checkpatch cleanups - formatting only
      include/asm-x86/vm86.h: checkpatch cleanups - formatting only
      include/asm-x86/vmi.h: checkpatch cleanups - formatting only
      include/asm-x86/voyager.h: checkpatch cleanups - formatting only
      include/asm-x86/xor_32.h: checkpatch cleanups - formatting only
      include/asm-x86/xor_64.h: checkpatch cleanups - formatting only
      include/asm-x86/ide.h: checkpatch cleanups - formatting only
      include/asm-x86/semaphore_32.h: checkpatch cleanups - formatting only
      include/asm-x86/semaphore_64.h: checkpatch cleanups - formatting only
      x86: include/asm-x86/pgalloc.h/bitops.h: checkpatch cleanups - formatting only
      include/asm-x86/string_32.h - style only
      x86: checkpatch cleanups - formatting only
      x86: include/asm-x86/pgalloc.h: checkpatch cleanups - formatting only

Johannes Weiner (1):
      x86: Remove redundant display of free swap space in show_mem()

Mark McLoughlin (3):
      xen: Module autoprobing support for frontend drivers
      xen: Add compatibility aliases for frontend drivers
      x86: move dma_supported and dma_set_mask to pci-dma_32.c

Markus Armbruster (3):
      xen: make hvc0 the preferred console in domU
      xen: Make xen-blkfront write its protocol ABI to xenstore
      xen pvfb: Para-virtual framebuffer, keyboard and pointer driver

Markus Metzger (1):
      x86, ptrace: PEBS support

Mathieu Desnoyers (3):
      x86: enhance DEBUG_RODATA support - alternatives
      x86 - Enhance DEBUG_RODATA support for hotplug and kprobes
      x86: fix test_poke for vmalloced pages

Mikael Pettersson (1):
      x86: correct/clarify comment in nops.h

Mike Travis (8):
      x86: clean up non-smp usage of cpu maps
      cpumask: add cpumask_scnprintf_len function
      x86: reduce memory and stack usage in intel_cacheinfo
      x86: oprofile: remove NR_CPUS arrays in arch/x86/oprofile/nmi_int.c
      asm-generic: add node_to_cpumask_ptr macro
      numa: move large array from stack to _initdata section
      cpumask: Cleanup more uses of CPU_MASK and NODE_MASK
      x86: modify Kconfig to allow up to 4096 cpus

Paolo Ciarrocchi (42):
      x86: coding style fixes for arch/x86/kernel/cpu/centaur.c
      x86: coding style fixes to arch/x86/lib/memmove_64.c
      x86: coding style fixes to arch/x86/kernel/syscall_64.c
      x86: coding style fixes to arch/x86/lib/string_32.c
      x86: coding style fixes to arch/x86/kernel/cpu/mcheck/p5.c
      x86: coding style fixes to arch/x86/kernel/x8664_ksyms_64.c
      x86: coding style fixes to arch/x86/oprofile/op_model_ppro.c
      x86: coding style fixes to arch/x86/oprofile/op_model_athlon.c
      x86: coding style fixes to arch/x86/mach-generic/probe.c
      x86: coding style fixes to arch/x86/mach-generic/default.c
      x86: coding style fixes to arch/x86/mach-generic/summit.c
      x86: coding style fixes to arch/x86/kernel/cpu/nexgen.c
      x86: coding style fixes to arch/x86/mach-generic/bigsmp.c
      x86: coding style fixes to arch/x86/kernel/cpu/mcheck/p6.c
      x86: coding style fixes to arch/x86/kernel/cpu/umc.c
      x86: coding style fixes to arch/x86/boot/compressed/misc.c
      x86: coding style fix to arch/x86/boot/pm.c
      x86: coding style fixes to arch/x86/kernel/summit_32.c
      x86: coding style fixes to arch/x86/kernel/cpu/intel.c
      x86: coding style fixes to arch/x86/oprofile/init.c
      x86: coding style fixes to arch/x86/lib/strstr_3
      x86: coding style fixes to arch/x86/kernel/mca_32.c
      x86: coding style fixes to arch/x86/kernel/cpu/mtrr/state.c
      x86: coding style fixes to arch/x86/lib/memcpy_32.c
      x86: coding style fixes to arch/x86/kernel/cpu/transmeta.c
      x86: coding style fixes to arch/x86/kernel/cpu/amd.c
      x86: coding style fixes to arch/x86/kernel/vm86_32.c
      x86: coding style fixes to arch/x86/kernel/cpu/mcheck/non-fatal.c
      x86: coding style fixes to arch/x86/kernel/cpu/mcheck/winchip.c
      x86: coding style fixes to arch/x86/kernel/cpu/mcheck/mce_32.c
      x86: coding style fixes to arch/x86/boot/cpucheck.c
      x86: coding style fixes to arch/x86/kernel/cpu/cyrix.c
      x86: coding style fixes to arch/x86/oprofile/nmi_timer_int.c
      x86: coding style fixes to arch/x86/kernel/msr.c
      x86: coding style fixes to arch/x86/xen/multicalls.c
      x86: coding style fixes to arch/x86/power/cpu_32.c
      x86: coding style fixes to arch/x86/kernel/cpu/common.c
      x86: coding style fixes to arch/x86/lib/usercopy_32.c
      x86: coding style fixes to arch/x86/kernel/early_printk.c
      x86: coding style fixes to x86/kernel/early_printk.c
      x86: coding style fixes to arch/x86/kernel/setup_32.c
      x86: coding style fixes to arch/x86/kernel/acpi/sleep.c

Pavel Machek (8):
      x86: wmb() confusion in system.h
      iommu: it could use some documentation
      x86: clean up aperture_64.c
      x86: fix iommu breaks usb after hibernation resume
      x86: iommu: use symbolic constants, not hardcoded numbers
      x86: clean up =0 initializations in arch/x86/kernel/tsc_32.c
      x86: move suspend wakeup code to C
      x86 gart: factor out common code

Pekka Enberg (2):
      x86: __show_registers() and __show_regs() API unification
      kmemcheck: support for x86-64

Pekka J Enberg (6):
      sysprof: minor cleanups
      sysprof: user pointer verification
      x86, sysprof: remove dead code
      x86, sysprof: clean up stack frame copying
      x86, sysprof: merge header to compilation unit
      kmemcheck: use pte helpers instead of ->pte_low

Randy Dunlap (2):
      x86: fix VisualWS and Voyager kexec build failures
      linux-next: Tree for April 10 (arch/x86)

Ravikiran G Thirumalai (5):
      x86: vSMP: Fix is_vsmp_box()
      x86: fix build breakage when PCI is define and PARAVIRT is not
      x86: vSMP: use pvops only if platform has the capability to support it
      x86: apic_is_clustered_box to indicate unsynched TSC's on multiboard vSMP systems
      x86: clean up vSMP detection

Robert Hancock (1):
      x86: validate against acpi motherboard resources

Robert P. J. Day (1):
      x86: Explicitly include required header files.

Robert Richter (1):
      x86: apic: extended interrupt LVT support for AMD

Roland McGrath (8):
      x86 vDSO: don't use disabled vDSO for signal trampoline
      x86 vdso: don't map 32-bit vdso when disabled
      x86: ia32 ptrace vs -ENOSYS
      x86: ptrace vs -ENOSYS
      x86: ia32 ptrace vs -ENOSYS sysenter/syscall
      x86: sys32_execve PT_DTRACE
      x86: handle_vm86_trap cleanup
      x86 vDSO: compile with -g, 64-bit

Roman Zippel (1):
      x86: fix recursive dependencies

Rusty Russell (1):
      x86: if we cannot calibrate the TSC, we panic.

Soren Sandmann (1):
      x86: add the debugfs interface for the sysprof tool

Steven Rostedt (1):
      ftrace: add notrace annotations for NMI routines

Suresh Siddha (5):
      srat, x86: add support for nodes spanning other nodes
      x86, fpu: split FPU state from task struct - v5
      x86, fpu: lazy allocation of FPU area - v5
      x86: fpu xstate split cleanup
      x86: fpu xstate split fix

Thomas Gleixner (8):
      x86: add debug info to DEBUG_PAGEALLOC
      cpa-debug-debugfs.patch
      pagetable-dumper-debugfs.patch
      x86: check physical address range in ioremap
      x86: replace the now useless max_pfn_mapped define
      input: fix PIT build bug on ppc64
      generic: find_next_bit() fix
      x86: tsc prevent time going backwards

Thomas Petazzoni (1):
      x86: use ELF section to list CPU vendor specific code

Vegard Nossum (7):
      x86: kmemcheck, v6
      x86: kmemcheck v7
      kmemcheck: check PTE before calling virt_to_page() on the address
      x86, kmemcheck: simplify shadow-address lookup logic
      kmemcheck: correct decoded size of movzbl instruction
      kmemcheck: one-shot mode
      x86: allocate fpu contexts with SLAB_NOTRACK flag

Venki Pallipadi (4):
      devmem: add range_is_allowed() check to mmap of /dev/mem
      x86: PAT bug fix for attribute type check after reserve_memtype
      x86: PAT infrastructure patch, documentation updates
      x86: PAT bug fix for attribute type check after reserve_memtype, debug

WANG Cong (1):
      x86: remove pointless comments

Yakov Lerner (1):
      x86, kprobes: correct post-eip value in post_hander()

Yinghai Lu (60):
      x86: clean up find_e820_area(), 64-bit
      x86_64: get apic_id later in acpi_numa_processor_affinity_init
      x86_64: remove never used nodenumer in pda
      x86: make amd quad core 8 socket system not be clustered_box, #2
      x86: clean up e820_reserve_resources on 64-bit
      x86_64: insert_resorce for lapic addr after e820_reserve_resources
      x86: apic_is_clustered_box for vsmp
      x86: remove wrong setting about CONSTANT_TSC for intel cpu
      x86_64: fix amd_detect_cmp
      x86: show apicid for cpu in proc
      x86: introduce initial apicid
      x86: sort address_markers for dump_pagetables
      x86_64: get boot_cpu_id as early for k8_scan_nodes
      x86: early memtest to find bad ram
      x86: allocate e820 resource struct all together
      smpboot integration
      x86: memtest bootparam
      x86: fix memtest print out
      x86: enable PAT for amd k8 and fam10h
      x86: pat cpu feature bit setting for known cpus
      x86: print out buggy mptable
      x86_64: do not reserve ramdisk two times
      x86: cleanup: change _end to end_before_pgt
      mm: make mem_map allocation continuous
      mm: fix alloc_bootmem_core to use fast searching for all nodes
      x86: clear pci_mmcfg_virt when mmcfg get rejected
      x86: mmconf enable mcfg early
      x86_64: set cfg_size for AMD Family 10h in case MMCONFIG
      x86_64: check and enable MMCONFIG for AMD Family 10h
      x86_64: check MSR to get MMCONFIG for AMD Family 10h
      x86: if acpi=off, force setting the mmconf for fam10h
      x86: seperate mmconf for fam10h out from setup_64.c
      try parent numa_node at first before using default v2
      x86: skip it if Fam 10h only handle bus 0
      ide: use dev_to_node instead of pcibus_to_node
      x86: remove unneeded check in mmconf reject
      mm: offset align in alloc_bootmem v3
      mm: make reserve_bootmem can crossed the nodes
      x86_64: make reserve_bootmem_generic to use new reserve_bootmem
      x86_64: fix setup_node_bootmem to support big mem excluding with memmap
      x86 pci: remove checking type for mmconfig probe v2
      x86: change pci_direct_conf1 back not static
      x86: reserve dma32 early for gart
      x86: get mp_bus_to_node early
      x86: use bus conf in NB conf fun1 to get bus range on, on 64-bit
      x86: multi pci root bus with different io resource range, on 64-bit
      x86/acpi: make dev_to_node return online node
      x86: double check the multi root bus with fam10h mmconf
      x86/pci: add pci=skip_isa_align command lines.
      net: use numa_node in net_devcice->dev instead of parent
      x86_64: don't need set default res if only have one root bus
      x86_64/mm: check and print vmemmap allocation continuous
      x86_64/mm: check and print vmemmap allocation continuous -fix
      acpi: get boot_cpu_id as early for k8_scan_nodes
      x86: work around io allocation overlap of HT links
      x86: agp_gart size checking for buggy device
      x86: checking aperture size order
      x86: add pci=check_enable_amd_mmconf and dmi check
      x86 PCI: call dmi_check_pciprobe()
      x86_64: allocate gart aperture from 512M

gorcunov@gmail.com (6):
      x86: relocate_kernel_32.S - clear register in more elegant way
      x86: relocate_kernel - use PAGE_SIZE instead of numeric constant
      x86: relocate_kernel - use predefined macroses for processor state
      x86: relocate_kernel - use predefined macroses for page attributes
      x86: cleanup - rename VM_MASK to X86_VM_MASK
      x86: replace most VM86 flags with flags from processor-flags.h

stephane eranian (3):
      x86: add cpu_has_arch_perfmon
      x86: add AMD Northbridge MSR definition
      x86: add AMD Northbridge PCI Id

venkatesh.pallipadi@intel.com (13):
      x86: PAT documentation
      x86: PAT infrastructure patch
      x86: PAT avoid aliasing in /dev/mem read/write
      x86: PAT make ioremap_change_attr non-static
      x86: PAT use reserve free memtype in ioremap and iounmap
      x86: PAT use reserve free memtype in set_memory_uc
      x86: PAT use reserve free memtype in pci_mmap_page_range
      x86: PAT phys_mem_access_prot_allowed for dev/mem mmap
      x86: PAT use reserve free memtype in mmap of /dev/mem
      x86: PAT add set_memory_wc() interface
      x86: PAT add ioremap_wc() interface
      x86: add PAT related debug prints
      x86: PAT export resource_wc in pci sysfs


^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-16 20:23 [v2.6.26] what's brewing in x86.git for v2.6.26 Ingo Molnar
@ 2008-04-16 20:37 ` Roland Dreier
  2008-04-16 22:18   ` Suresh Siddha
  2008-04-16 20:50 ` Andi Kleen
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 71+ messages in thread
From: Roland Dreier @ 2008-04-16 20:37 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

 >  - PAT support - first step towards phasing out MTRR's for cache 
 >    attribute control

I just grabbed your tree and I see that there is no
pgprot_writecombine() for x86.  I see that pci_mmap_page_range() handles
write combining but there's no way for a PCI driver to allow userspace
to mmap() part of a BAR with WC enabled.  Doing this gives a big
performance boost for running low-latency apps on InfiniBand hardware
driven by the mlx4 driver (look for the FIXME about it in
drivers/infiniband/hw/mlx4/main.c).  Are there any plans to handle this
somehow?

Thanks,
  Roland

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-16 20:23 [v2.6.26] what's brewing in x86.git for v2.6.26 Ingo Molnar
  2008-04-16 20:37 ` Roland Dreier
@ 2008-04-16 20:50 ` Andi Kleen
  2008-04-17 10:06   ` Alexander van Heukelum
  2008-04-17  7:25 ` Andrew Morton
                   ` (2 subsequent siblings)
  4 siblings, 1 reply; 71+ messages in thread
From: Andi Kleen @ 2008-04-16 20:50 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

Ingo Molnar <mingo@elte.hu> writes:

>  - generalized bitops - they are faster and smaller.

Faster in a 100% bogus benchmark with the most unrealistic input data
set one can imagine with some effort. They might be faster or they
might be slower, nobody really knows currently.

-Andi

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-16 20:37 ` Roland Dreier
@ 2008-04-16 22:18   ` Suresh Siddha
  0 siblings, 0 replies; 71+ messages in thread
From: Suresh Siddha @ 2008-04-16 22:18 UTC (permalink / raw)
  To: Roland Dreier; +Cc: Ingo Molnar, linux-kernel, venkatesh.pallipadi

On Wed, Apr 16, 2008 at 01:37:30PM -0700, Roland Dreier wrote:
>  >  - PAT support - first step towards phasing out MTRR's for cache 
>  >    attribute control
> 
> I just grabbed your tree and I see that there is no
> pgprot_writecombine() for x86.  I see that pci_mmap_page_range() handles
> write combining but there's no way for a PCI driver to allow userspace
> to mmap() part of a BAR with WC enabled.  Doing this gives a big
> performance boost for running low-latency apps on InfiniBand hardware
> driven by the mlx4 driver (look for the FIXME about it in
> drivers/infiniband/hw/mlx4/main.c).  Are there any plans to handle this
> somehow?

Yes. We are planning to fix this by tracking the attribute usage specified
in the pgprot field of remap_pfn_range(). Once the attribute is tracked
properly, we can add pgprot_writecombine() for WC case.

This should also help the other drivers like video fb etc which specify
the UC/WC attribute for user level mmap.

thanks,
suresh

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-16 20:23 [v2.6.26] what's brewing in x86.git for v2.6.26 Ingo Molnar
  2008-04-16 20:37 ` Roland Dreier
  2008-04-16 20:50 ` Andi Kleen
@ 2008-04-17  7:25 ` Andrew Morton
  2008-04-17  7:45   ` Pekka Enberg
                     ` (2 more replies)
  2008-04-17  7:48 ` Andrew Morton
  2008-04-18  6:27 ` Andrew Morton
  4 siblings, 3 replies; 71+ messages in thread
From: Andrew Morton @ 2008-04-17  7:25 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel, Linus Torvalds

On Wed, 16 Apr 2008 22:23:38 +0200 Ingo Molnar <mingo@elte.hu> wrote:

> 
> what's brewing in x86.git for v2.6.26?

How much of this has not been in -mm?

How much of this has not been in linux-next?

> too many topics to list them all - there are 884 patches from 74 authors 
> at the moment.
> 
> a few highlights:
> 
>  - 4096 CPUs support. (Yes, such big boxes exist, and they run Linux.)
> 
>  - mmiotrace feature: trace accesses to hw components to help figure out 
>    how they are programmed.
> 
>  - kmemcheck feature: Valgrind for the native Linux kernel in essence - 
>    detects access to uninitialized memory.
> 
>  - ftrace plugin for sysprof

sysprof is crap.

>  - fixed StackProtector security feature (these fixes were too intrusive 
>    for v2.6.25)
> 
>  - lazy FPU allocation/speedup - offloaded/large FPU/SSE state support
> 
>  - SMP-boot, mpparse, DMA ops unification
> 
>  - PAT support - first step towards phasing out MTRR's for cache 
>    attribute control
> 
>  - enable GBPAGES - faster TLB misses on CPUs that support it
> 
>  - debug helper: view kernel pagetable layout via debugfs

Needs documentation.

>       x86: introduce /dev/mem restrictions with a config option

This should be runtime-settable, not build-time settable.

> ...
>
> Randy Dunlap (2):
> ...
>       linux-next: Tree for April 10 (arch/x86)

borked patch title.

> Soren Sandmann (1):
>       x86: add the debugfs interface for the sysprof tool

There were serious objections that this is weaker than and duplicative of
oprofile which were not adequately addressed.

Also, I (and apparently only I) actually reviewed the implementation and
found it to be riddled with bugs and shortcomings.  afacit this was
completely ignored and you propose to merge it anwyay?


I obviously don't have time to go through it all, but I'm afraid I cannot
be very confident in it.  All I can say is "the parts which have been in
-mm seem to compile and run".  A quick grep indicates that only 644 of
these 884 patches are in -mm.  And a lot of them only turned up a week or
two ago.

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17  7:25 ` Andrew Morton
@ 2008-04-17  7:45   ` Pekka Enberg
  2008-04-17  8:20     ` Andrew Morton
  2008-04-17  8:14   ` Andrew Morton
  2008-04-17  8:30   ` Ingo Molnar
  2 siblings, 1 reply; 71+ messages in thread
From: Pekka Enberg @ 2008-04-17  7:45 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Ingo Molnar, linux-kernel, Linus Torvalds

On Thu, Apr 17, 2008 at 10:25 AM, Andrew Morton
<akpm@linux-foundation.org> wrote:
>  > Soren Sandmann (1):
>  >       x86: add the debugfs interface for the sysprof tool
>
>  Also, I (and apparently only I) actually reviewed the implementation and
>  found it to be riddled with bugs and shortcomings.  afacit this was
>  completely ignored and you propose to merge it anwyay?

No, I fixed some of those and I think Ingo/Soren did the rest. But it
needs another round of review on LKML for sure.

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-16 20:23 [v2.6.26] what's brewing in x86.git for v2.6.26 Ingo Molnar
                   ` (2 preceding siblings ...)
  2008-04-17  7:25 ` Andrew Morton
@ 2008-04-17  7:48 ` Andrew Morton
  2008-04-18  6:27 ` Andrew Morton
  4 siblings, 0 replies; 71+ messages in thread
From: Andrew Morton @ 2008-04-17  7:48 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

On Wed, 16 Apr 2008 22:23:38 +0200 Ingo Molnar <mingo@elte.hu> wrote:

>       kgdb: light v16

probe_kernel_address() should be removed and reimplemented using the new
probe_kernel_read().


^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17  7:25 ` Andrew Morton
  2008-04-17  7:45   ` Pekka Enberg
@ 2008-04-17  8:14   ` Andrew Morton
  2008-04-17  8:57     ` Avi Kivity
                       ` (2 more replies)
  2008-04-17  8:30   ` Ingo Molnar
  2 siblings, 3 replies; 71+ messages in thread
From: Andrew Morton @ 2008-04-17  8:14 UTC (permalink / raw)
  To: Ingo Molnar, linux-kernel, Linus Torvalds

On Thu, 17 Apr 2008 00:25:52 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:

> A quick grep indicates that only 644 of
> these 884 patches are in -mm.  And a lot of them only turned up a week or
> two ago.

I did a test merge.

- About 13 patch rejects agaisnt git-kvm

- Multiple minor rejects aginst the IDE tree, the PCI tree

- Minor bustage of git-semaphore

- Several core MM patches which I also had merged.  I didn't check fully
  whether they are the same.

- extensive damage to the page-flags patches

  Did you check that all architectures and configurations still have
  sufficient page flags for us to be able to consume another one for
  kmemcheck?  The MM developers have put much, much effort into avoiding
  running out of flags over numerous years and afaik none of them even know
  that this debug feature is using one of the few remaining ones.

  What do we do when we run out?

- rejects in capabilities-implement-per-process-securebits.patch

- The proposed PR_GET_TSC and PR_SET_TSC have the same values as
  PR_GET_SECUREBITS and PR_SET_SECUREBITS.  Because we never knew this
  before we didn't get to discuss which one needs to be altered as we
  normally would.

- several rejects in
  x86-olpc-add-one-laptop-per-child-architecture-support.patch

- several bitops patches (use-__fls-for-fls64-on-64-bit-archs, etc) were
  also in -mm.  I did not check for differences between the two versions.

  These are not x86 patches.

- maybe ten-odd minor rejects in other places.


So not as bad as it might have been.  kvm and page-flags are the major
problems.  Of course, none of this has been compiled and this proposed code
combination has never been tested by anyone at runtime.


^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17  7:45   ` Pekka Enberg
@ 2008-04-17  8:20     ` Andrew Morton
  2008-04-17  8:32       ` Pekka J Enberg
  0 siblings, 1 reply; 71+ messages in thread
From: Andrew Morton @ 2008-04-17  8:20 UTC (permalink / raw)
  To: Pekka Enberg; +Cc: Ingo Molnar, linux-kernel, Linus Torvalds

On Thu, 17 Apr 2008 10:45:59 +0300 "Pekka Enberg" <penberg@cs.helsinki.fi> wrote:

> On Thu, Apr 17, 2008 at 10:25 AM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
> >  > Soren Sandmann (1):
> >  >       x86: add the debugfs interface for the sysprof tool
> >
> >  Also, I (and apparently only I) actually reviewed the implementation and
> >  found it to be riddled with bugs and shortcomings.  afacit this was
> >  completely ignored and you propose to merge it anwyay?
> 
> No, I fixed some of those and I think Ingo/Soren did the rest. But it
> needs another round of review on LKML for sure.

afaict none of my review comments have been addressed in the sysprof.c which
is in -mm.  It has the following commits:

    x86, sysprof: merge header to compilation unit
    x86, sysprof: clean up stack frame copying
    x86, sysprof: remove dead code
    sysprof: user pointer verification
    sysprof: minor cleanups
    x86: add the debugfs interface for the sysprof tool

I received no email even acknowledging the review comments.

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17  7:25 ` Andrew Morton
  2008-04-17  7:45   ` Pekka Enberg
  2008-04-17  8:14   ` Andrew Morton
@ 2008-04-17  8:30   ` Ingo Molnar
  2008-04-17  8:40     ` Andrew Morton
  2 siblings, 1 reply; 71+ messages in thread
From: Ingo Molnar @ 2008-04-17  8:30 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-kernel, Linus Torvalds, Thomas Gleixner, H. Peter Anvin


* Andrew Morton <akpm@linux-foundation.org> wrote:

> On Wed, 16 Apr 2008 22:23:38 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> 
> > 
> > what's brewing in x86.git for v2.6.26?
>
> How much of this has not been in -mm?

all of these are in linux-next, and most of them are in -mm.
 
the for-akpm branch has 646 commits at the moment (these are the ones 
that are in -mm), out of 890 patches. These are the "pure arch/x86" 
topic patches, and which will be offered in the first wave of pull 
requests.

Of the remaining patches, they'll be offered under different topics, in 
different temporary branches (or trees) depending on which subsystem 
they interact with. There will be no "take it or leave it" big pull 
request.

Some patches are later in the queue because they depend on generic 
infrastructure.

Some wont be offered for a pull at all because they belong into other 
subsystems and we just track them via x86.git because it's some 
important topic or dangerous-looking patch we'd like to see the effects 
of first-hand.

[ sorry about not having described this in detail in my mail - i spent 
  the last 3 work days on a 2.6.25 regression almost non-stop, so x86 
  queue cleanup lagged behind a bit and my description of the changes 
  was rather terse. ]

> How much of this has not been in linux-next?

none.

but we do much more testing than just getting code into other trees. We 
cross-build 96 different configurations on other non-x86 architectures:

  http://www.tglx.de/autoqa-cgi/index?run=81&tree=1

last night's run was: 96 out of 96 configs built successfully.

This covers: alpha, arm, mips, powerpc, sparc64, x86, m32r, powerpc, 
xtensa, mips, sh, sparc, parisc, powerpc. We test the various branches 
(amongst them for-akpm) and combination trees as well.

and the backbone of arch/x86 QA we do are the build, boot and stress 
tests we do on x86: we ran and booted thousands of x86 randconfigs in 
the past few days alone. x86/latest boots and works from the smallest 
boxes up to a 64-way testbox. On the 64-way box i did a 1 week burn-in 
stress-test last week as well, for any longer-term effects.

> >  - ftrace plugin for sysprof
> 
> sysprof is crap.

you mean the original hack? Sure, that had a number of problems and we 
are not offering that for a merge.

But have you seen the latest code we are offering for merge? Check out 
sched-devel/latest and kernel/trace/trace_sysprof.c. Nicely generalized 
on top of stacktrace.h, put into the ftrace framework, userspace has 
been ported to that too. No more special sysprof-only API hack.

> >  - debug helper: view kernel pagetable layout via debugfs
> 
> Needs documentation.

ok, will fix.

> >       x86: introduce /dev/mem restrictions with a config option
> 
> This should be runtime-settable, not build-time settable.

... that defeats one of the security purposes of this feature. (which is 
to make it a bit harder for rootkits to just patch themselves in via 
/dev/mem)

> > Randy Dunlap (2):
> > ...
> >       linux-next: Tree for April 10 (arch/x86)
> 
> borked patch title.

thanks, fixed. This patch will be backmerged shortly before pushout 
anyway (like you do for -mm, to maintain bisectability) so the title 
does not matter (the fix and credit will be added to the original 
patch).

Note that this is from the tail of the queue - not all commit entries 
are sanitized yet.

> > Soren Sandmann (1):
> >       x86: add the debugfs interface for the sysprof tool
> 
> There were serious objections that this is weaker than and duplicative 
> of oprofile which were not adequately addressed.
> 
> Also, I (and apparently only I) actually reviewed the implementation 
> and found it to be riddled with bugs and shortcomings.  afacit this 
> was completely ignored and you propose to merge it anwyay?

no.

I think what caused the confusion is that the cleaned up sysprof ftrace 
plugin depends on the presence of the ftrace infrastructure, which is in 
sched-devel. The patch you see in x86.git is the (now obsolete, and 
removed) sysprof code. Those interim commits show up in the shortlog but 
we (of course) wont push them upstream. Sorry about the confusion ...

i just cleaned this up and pushed out a new x86.git and sched.git.

	Ingo

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17  8:20     ` Andrew Morton
@ 2008-04-17  8:32       ` Pekka J Enberg
  2008-04-17  8:34         ` Pekka Enberg
  0 siblings, 1 reply; 71+ messages in thread
From: Pekka J Enberg @ 2008-04-17  8:32 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Ingo Molnar, linux-kernel, Linus Torvalds

On Thu, 17 Apr 2008, Andrew Morton wrote:
> > No, I fixed some of those and I think Ingo/Soren did the rest. But it
> > needs another round of review on LKML for sure.
> 
> afaict none of my review comments have been addressed in the sysprof.c which
> is in -mm.  It has the following commits:
> 
>     x86, sysprof: merge header to compilation unit
>     x86, sysprof: clean up stack frame copying
>     x86, sysprof: remove dead code
>     sysprof: user pointer verification
>     sysprof: minor cleanups
>     x86: add the debugfs interface for the sysprof tool
> 
> I received no email even acknowledging the review comments.

Oh sorry, I guess I fixed up problems I spot myself. There indeed seem to 
be some comments by Andrew that have not been addressed:

  http://lkml.org/lkml/2008/2/23/68

			Pekka

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17  8:32       ` Pekka J Enberg
@ 2008-04-17  8:34         ` Pekka Enberg
  2008-04-17  8:40           ` Ingo Molnar
  2008-04-17  8:42           ` Andrew Morton
  0 siblings, 2 replies; 71+ messages in thread
From: Pekka Enberg @ 2008-04-17  8:34 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Ingo Molnar, linux-kernel, Linus Torvalds

On Thu, Apr 17, 2008 at 11:32 AM, Pekka J Enberg <penberg@cs.helsinki.fi> wrote:
>  Oh sorry, I guess I fixed up problems I spot myself. There indeed seem to
>  be some comments by Andrew that have not been addressed:

s/have not/might have not/

>   http://lkml.org/lkml/2008/2/23/68

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17  8:34         ` Pekka Enberg
@ 2008-04-17  8:40           ` Ingo Molnar
  2008-04-17  8:42           ` Andrew Morton
  1 sibling, 0 replies; 71+ messages in thread
From: Ingo Molnar @ 2008-04-17  8:40 UTC (permalink / raw)
  To: Pekka Enberg; +Cc: Andrew Morton, linux-kernel, Linus Torvalds


* Pekka Enberg <penberg@cs.helsinki.fi> wrote:

> On Thu, Apr 17, 2008 at 11:32 AM, Pekka J Enberg <penberg@cs.helsinki.fi> wrote:
> >  Oh sorry, I guess I fixed up problems I spot myself. There indeed 
> >  seem to be some comments by Andrew that have not been addressed:
> 
> s/have not/might have not/
> 
> >   http://lkml.org/lkml/2008/2/23/68

at a quick glance most of the fundamental ones are addressed (it now 
uses per-cpu hrtimers, not the timer hook, etc.), but i'll go over it 
with a fine comb as well to make sure everything Andrew pointed out is 
addressed.

	Ingo

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17  8:30   ` Ingo Molnar
@ 2008-04-17  8:40     ` Andrew Morton
  2008-04-17  8:45       ` David Miller
  2008-04-17  9:06       ` Ingo Molnar
  0 siblings, 2 replies; 71+ messages in thread
From: Andrew Morton @ 2008-04-17  8:40 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel, Linus Torvalds, Thomas Gleixner, H. Peter Anvin

On Thu, 17 Apr 2008 10:30:00 +0200 Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > On Wed, 16 Apr 2008 22:23:38 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> > How much of this has not been in linux-next?
> 
> none.

That's a relief.  Please keep it this way - I plan on basing -mm on
linux-next after 2.6.26-rc1 and that should prevent reoccurrences.

> but we do much more testing than just getting code into other trees. We 
> cross-build 96 different configurations on other non-x86 architectures:
> 
>   http://www.tglx.de/autoqa-cgi/index?run=81&tree=1
> 
> last night's run was: 96 out of 96 configs built successfully.
> 
> This covers: alpha, arm, mips, powerpc, sparc64, x86, m32r, powerpc, 
> xtensa, mips, sh, sparc, parisc, powerpc. We test the various branches 
> (amongst them for-akpm) and combination trees as well.
> 
> and the backbone of arch/x86 QA we do are the build, boot and stress 
> tests we do on x86: we ran and booted thousands of x86 randconfigs in 
> the past few days alone. x86/latest boots and works from the smallest 
> boxes up to a 64-way testbox. On the 64-way box i did a 1 week burn-in 
> stress-test last week as well, for any longer-term effects.

That's nowhere as useful as it could be.

By keeping all this code out of -mm you haven't solved any of the
merge/integration problems which we had in 2.6.24-rcX.  They're all still
there.  All you did was to push them out of the two-month
integrate-and-test period and put them into the 2.6.25 merge window
instead.

> > >  - ftrace plugin for sysprof
> > 
> > sysprof is crap.
> 
> you mean the original hack? Sure, that had a number of problems and we 
> are not offering that for a merge.

whew.

> But have you seen the latest code we are offering for merge?

No.  Was it ever sent out for review?

> Check out 
> sched-devel/latest and kernel/trace/trace_sysprof.c. Nicely generalized 
> on top of stacktrace.h, put into the ftrace framework, userspace has 
> been ported to that too. No more special sysprof-only API hack.

Would prefer to not have to go fishing in git trees to find code to review.



^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17  8:34         ` Pekka Enberg
  2008-04-17  8:40           ` Ingo Molnar
@ 2008-04-17  8:42           ` Andrew Morton
  2008-04-17 11:49             ` Christoph Hellwig
  1 sibling, 1 reply; 71+ messages in thread
From: Andrew Morton @ 2008-04-17  8:42 UTC (permalink / raw)
  To: Pekka Enberg; +Cc: Ingo Molnar, linux-kernel, Linus Torvalds

On Thu, 17 Apr 2008 11:34:25 +0300 "Pekka Enberg" <penberg@cs.helsinki.fi> wrote:

> On Thu, Apr 17, 2008 at 11:32 AM, Pekka J Enberg <penberg@cs.helsinki.fi> wrote:
> >  Oh sorry, I guess I fixed up problems I spot myself. There indeed seem to
> >  be some comments by Andrew that have not been addressed:
> 
> s/have not/might have not/
> 
> >   http://lkml.org/lkml/2008/2/23/68

Apparently that code is not being proposed for merge and it all got
reimplemented and moved elsewhere.  I knew nothing of this.

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17  8:40     ` Andrew Morton
@ 2008-04-17  8:45       ` David Miller
  2008-04-17  8:54         ` Andrew Morton
  2008-04-17  9:06       ` Ingo Molnar
  1 sibling, 1 reply; 71+ messages in thread
From: David Miller @ 2008-04-17  8:45 UTC (permalink / raw)
  To: akpm; +Cc: mingo, linux-kernel, torvalds, tglx, hpa

From: Andrew Morton <akpm@linux-foundation.org>
Date: Thu, 17 Apr 2008 01:40:54 -0700

> By keeping all this code out of -mm you haven't solved any of the
> merge/integration problems which we had in 2.6.24-rcX.

I think things would have been a lot easier if you had adopted
basing -mm on top of linux-next from the very start.

The responsiveness to problems and merge hassles has been so much
superior and efficient from the linux-next folks for my networking
stuff, for example.  It's never been like that with -mm.

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17  8:45       ` David Miller
@ 2008-04-17  8:54         ` Andrew Morton
  2008-04-17  8:56           ` Andrew Morton
  2008-04-17  9:19           ` David Miller
  0 siblings, 2 replies; 71+ messages in thread
From: Andrew Morton @ 2008-04-17  8:54 UTC (permalink / raw)
  To: David Miller; +Cc: mingo, linux-kernel, torvalds, tglx, hpa

On Thu, 17 Apr 2008 01:45:34 -0700 (PDT) David Miller <davem@davemloft.net> wrote:

> From: Andrew Morton <akpm@linux-foundation.org>
> Date: Thu, 17 Apr 2008 01:40:54 -0700
> 
> > By keeping all this code out of -mm you haven't solved any of the
> > merge/integration problems which we had in 2.6.24-rcX.
> 
> I think things would have been a lot easier if you had adopted
> basing -mm on top of linux-next from the very start.

linux-next ramped up across the 2.6.25-rc window and I wanted to give it
some time to see how it would pan out.

> The responsiveness to problems and merge hassles has been so much
> superior and efficient from the linux-next folks for my networking
> stuff, for example.  It's never been like that with -mm.

I don't know what you mena by this.  But linux-next integrates only the
other subsystem trees and they have rarely caused me integration problems
against git-net.  

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17  8:54         ` Andrew Morton
@ 2008-04-17  8:56           ` Andrew Morton
  2008-04-17  9:19           ` David Miller
  1 sibling, 0 replies; 71+ messages in thread
From: Andrew Morton @ 2008-04-17  8:56 UTC (permalink / raw)
  To: David Miller, mingo, linux-kernel, torvalds, tglx, hpa

On Thu, 17 Apr 2008 01:54:25 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:

> But linux-next integrates only the
> other subsystem trees and they have rarely caused me integration problems
> against git-net.  

Well.  git-lblnet was a big problem but it was a once off.

git-wireless used to cause problems but that's now merging into git-net
more often.

git-netdev-all was sometimes a problem but that's gone altogether.

So git-net integration because much simpler during 2.6.25-rcX.

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17  8:14   ` Andrew Morton
@ 2008-04-17  8:57     ` Avi Kivity
  2008-04-17 10:32     ` Johannes Weiner
  2008-04-17 11:49     ` Christoph Hellwig
  2 siblings, 0 replies; 71+ messages in thread
From: Avi Kivity @ 2008-04-17  8:57 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Ingo Molnar, linux-kernel, Linus Torvalds

Andrew Morton wrote:
> On Thu, 17 Apr 2008 00:25:52 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
>   
>> A quick grep indicates that only 644 of
>> these 884 patches are in -mm.  And a lot of them only turned up a week or
>> two ago.
>>     
>
> I did a test merge.
>
> - About 13 patch rejects agaisnt git-kvm
>
>
>   
[...]

> So not as bad as it might have been.  kvm and page-flags are the major
> problems.  Of course, none of this has been compiled and this proposed code
> combination has never been tested by anyone at runtime.
>
>   

Once git-x86 is pulled, I will rebase kvm.git against -linus, retest, 
and submit (have to wait for s390 and ia64 anyway).

-- 
error compiling committee.c: too many arguments to function


^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17  8:40     ` Andrew Morton
  2008-04-17  8:45       ` David Miller
@ 2008-04-17  9:06       ` Ingo Molnar
  2008-04-17  9:18         ` Andrew Morton
  1 sibling, 1 reply; 71+ messages in thread
From: Ingo Molnar @ 2008-04-17  9:06 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-kernel, Linus Torvalds, Thomas Gleixner, H. Peter Anvin


* Andrew Morton <akpm@linux-foundation.org> wrote:

> By keeping all this code out of -mm you haven't solved any of the 
> merge/integration problems which we had in 2.6.24-rcX.  They're all 
> still there.  All you did was to push them out of the two-month 
> integrate-and-test period and put them into the 2.6.25 merge window 
> instead.

... hm, i think there's really no problem here at all: most of the merge 
problems you cited were due to clearly out-of-tree patches that sit in 
x86.git/testing for the convenience of our testers and contributors, 
that we have no intention to push upstream.

(Again, sorry about the terse shortlog which might have contributed to 
this misunderstanding, that's all i could do yesterday evening.)

	Ingo

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17  9:06       ` Ingo Molnar
@ 2008-04-17  9:18         ` Andrew Morton
  2008-04-17  9:30           ` Ingo Molnar
  0 siblings, 1 reply; 71+ messages in thread
From: Andrew Morton @ 2008-04-17  9:18 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel, Linus Torvalds, Thomas Gleixner, H. Peter Anvin

On Thu, 17 Apr 2008 11:06:26 +0200 Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > By keeping all this code out of -mm you haven't solved any of the 
> > merge/integration problems which we had in 2.6.24-rcX.  They're all 
> > still there.  All you did was to push them out of the two-month 
> > integrate-and-test period and put them into the 2.6.25 merge window 
> > instead.
> 
> ... hm, i think there's really no problem here at all: most of the merge 
> problems you cited were due to clearly out-of-tree patches that sit in 
> x86.git/testing for the convenience of our testers and contributors, 
> that we have no intention to push upstream.

Are those out-of-tree patches also in linux-next?  The page-flags and prctl
changes are there.  And those are planned for 2.6.26, aren't they?



^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17  8:54         ` Andrew Morton
  2008-04-17  8:56           ` Andrew Morton
@ 2008-04-17  9:19           ` David Miller
  2008-04-17  9:33             ` Andrew Morton
  1 sibling, 1 reply; 71+ messages in thread
From: David Miller @ 2008-04-17  9:19 UTC (permalink / raw)
  To: akpm; +Cc: mingo, linux-kernel, torvalds, tglx, hpa

From: Andrew Morton <akpm@linux-foundation.org>
Date: Thu, 17 Apr 2008 01:54:25 -0700

> linux-next ramped up across the 2.6.25-rc window and I wanted to give it
> some time to see how it would pan out.
...
> I don't know what you mena by this.  But linux-next integrates only the
> other subsystem trees and they have rarely caused me integration problems
> against git-net.  

Fair enough, thanks for the explanation.

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17  9:18         ` Andrew Morton
@ 2008-04-17  9:30           ` Ingo Molnar
  2008-04-17  9:36             ` Andrew Morton
  2008-04-17  9:53             ` Andrew Morton
  0 siblings, 2 replies; 71+ messages in thread
From: Ingo Molnar @ 2008-04-17  9:30 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-kernel, Linus Torvalds, Thomas Gleixner, H. Peter Anvin


* Andrew Morton <akpm@linux-foundation.org> wrote:

> > > By keeping all this code out of -mm you haven't solved any of the 
> > > merge/integration problems which we had in 2.6.24-rcX.  They're 
> > > all still there.  All you did was to push them out of the 
> > > two-month integrate-and-test period and put them into the 2.6.25 
> > > merge window instead.
> > 
> > ... hm, i think there's really no problem here at all: most of the 
> > merge problems you cited were due to clearly out-of-tree patches 
> > that sit in x86.git/testing for the convenience of our testers and 
> > contributors, that we have no intention to push upstream.
> 
> Are those out-of-tree patches also in linux-next? [...]

yes they are.

> [...]  The page-flags and prctl changes are there.  And those are 
> planned for 2.6.26, aren't they?

you mean kmemcheck? Yes, that's planned. We've been working 4 months 
non-stop on kmemcheck to make it mergeable and usable, it's at version 7 
right now, and it caught a handful of real bugs already (such as 
63a7138671c - unfortunately not credited in the log to kmemcheck). But 
because it touches SLUB (because it has to - and they are acked by 
Pekka) i never had the chance to move it into the for-akpm branch.

i guess this will all sort itself out when you rebase -mm to linux-next. 
Stephen Rothwell is doing an excellent job of resolving interactions 
between trees.

	Ingo

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17  9:19           ` David Miller
@ 2008-04-17  9:33             ` Andrew Morton
  0 siblings, 0 replies; 71+ messages in thread
From: Andrew Morton @ 2008-04-17  9:33 UTC (permalink / raw)
  To: David Miller; +Cc: mingo, linux-kernel, torvalds, tglx, hpa

On Thu, 17 Apr 2008 02:19:35 -0700 (PDT) David Miller <davem@davemloft.net> wrote:

> From: Andrew Morton <akpm@linux-foundation.org>
> Date: Thu, 17 Apr 2008 01:54:25 -0700
> 
> > linux-next ramped up across the 2.6.25-rc window and I wanted to give it
> > some time to see how it would pan out.
> ...
> > I don't know what you mena by this.  But linux-next integrates only the
> > other subsystem trees and they have rarely caused me integration problems
> > against git-net.  

There are maybe as many as 100 "subsystem trees" hosted in -mm.  Stuff like
md, ipmi, tty, elf, keys, procfs, char drivers, nbd, fbdev, aoe, fuse, edac
and the list goes on.

Once I get -mm based on linux-next, the next step is to somehow feed those
trees (well, the "stable" parts thereof) back into linux-next while not
losing track of all the patches.  I haven't a clue how I'll do this ;)

But I haven't thought about it much yet.

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17  9:30           ` Ingo Molnar
@ 2008-04-17  9:36             ` Andrew Morton
  2008-04-17  9:46               ` Ingo Molnar
                                 ` (3 more replies)
  2008-04-17  9:53             ` Andrew Morton
  1 sibling, 4 replies; 71+ messages in thread
From: Andrew Morton @ 2008-04-17  9:36 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel, Linus Torvalds, Thomas Gleixner, H. Peter Anvin

On Thu, 17 Apr 2008 11:30:25 +0200 Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > > > By keeping all this code out of -mm you haven't solved any of the 
> > > > merge/integration problems which we had in 2.6.24-rcX.  They're 
> > > > all still there.  All you did was to push them out of the 
> > > > two-month integrate-and-test period and put them into the 2.6.25 
> > > > merge window instead.
> > > 
> > > ... hm, i think there's really no problem here at all: most of the 
> > > merge problems you cited were due to clearly out-of-tree patches 
> > > that sit in x86.git/testing for the convenience of our testers and 
> > > contributors, that we have no intention to push upstream.
> > 
> > Are those out-of-tree patches also in linux-next? [...]
> 
> yes they are.
> 
> > [...]  The page-flags and prctl changes are there.  And those are 
> > planned for 2.6.26, aren't they?
> 
> you mean kmemcheck? Yes, that's planned. We've been working 4 months 
> non-stop on kmemcheck to make it mergeable and usable, it's at version 7 
> right now, and it caught a handful of real bugs already (such as 
> 63a7138671c - unfortunately not credited in the log to kmemcheck). But 
> because it touches SLUB (because it has to - and they are acked by 
> Pekka) i never had the chance to move it into the for-akpm branch.

Does it really really really need to consume one of our few remaining page
flags?  We'll be in a mess when we run out.

> i guess this will all sort itself out when you rebase -mm to linux-next. 
> Stephen Rothwell is doing an excellent job of resolving interactions 
> between trees.

Yep I expect it'll help in several ways.  (That's why I suggested it!)

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17  9:36             ` Andrew Morton
@ 2008-04-17  9:46               ` Ingo Molnar
  2008-04-17 10:06                 ` Andrew Morton
  2008-04-17 10:11               ` Andi Kleen
                                 ` (2 subsequent siblings)
  3 siblings, 1 reply; 71+ messages in thread
From: Ingo Molnar @ 2008-04-17  9:46 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-kernel, Linus Torvalds, Thomas Gleixner, H. Peter Anvin


* Andrew Morton <akpm@linux-foundation.org> wrote:

> > you mean kmemcheck? Yes, that's planned. We've been working 4 months 
> > non-stop on kmemcheck to make it mergeable and usable, it's at 
> > version 7 right now, and it caught a handful of real bugs already 
> > (such as 63a7138671c - unfortunately not credited in the log to 
> > kmemcheck). But because it touches SLUB (because it has to - and 
> > they are acked by Pekka) i never had the chance to move it into the 
> > for-akpm branch.
> 
> Does it really really really need to consume one of our few remaining 
> page flags?  We'll be in a mess when we run out.

well AFAICS the shortage really mostly affects 32-bit platforms. And 
there we've got 19 bits used, out of 23 available, right?

whether we track a page or not is rather fundamental to kmemcheck, i 
dont see any easy way to get rid of that usage. (and since kmemcheck is 
a transparent add-on, i dont see any obvious other candidate like 
page->private either - all those fields might be utilized)

if we run out of that in the future: the high bits get used by sparse 
section and numa node ID bits, worst-case we could live with restricting 
the max number of NUMA nodes on 32-bit from 64 to 32? [NUMA on 32-bit is 
an afterthought anyway.] Or we could do a CONFIG_KMEMCHECK=y only 
page->flags_debug.

	Ingo

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17  9:30           ` Ingo Molnar
  2008-04-17  9:36             ` Andrew Morton
@ 2008-04-17  9:53             ` Andrew Morton
  1 sibling, 0 replies; 71+ messages in thread
From: Andrew Morton @ 2008-04-17  9:53 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel, Linus Torvalds, Thomas Gleixner, H. Peter Anvin


btw: ftrace.  I didn't pay much attention to the early patches when they
flew past a couple of months ago and there's been basically no email about
it since (unless it's on some other list?)

Changelogs don't seem to explain it much and it seems to be undocumented. 
It's nicely commented, but it would be useful to at least present the
kernel<->userspace API in a way which can be reviewed.


You'd think that uninlining ftrace_ip_in_hash() would save a few bytes, but
it saves zero.  Even noinline doesn't change it.  Weird.

<checks>

hm, gcc has gone and ignored the `inline'.  heh.

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17  9:46               ` Ingo Molnar
@ 2008-04-17 10:06                 ` Andrew Morton
  0 siblings, 0 replies; 71+ messages in thread
From: Andrew Morton @ 2008-04-17 10:06 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel, Linus Torvalds, Thomas Gleixner, H. Peter Anvin

On Thu, 17 Apr 2008 11:46:06 +0200 Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > > you mean kmemcheck? Yes, that's planned. We've been working 4 months 
> > > non-stop on kmemcheck to make it mergeable and usable, it's at 
> > > version 7 right now, and it caught a handful of real bugs already 
> > > (such as 63a7138671c - unfortunately not credited in the log to 
> > > kmemcheck). But because it touches SLUB (because it has to - and 
> > > they are acked by Pekka) i never had the chance to move it into the 
> > > for-akpm branch.
> > 
> > Does it really really really need to consume one of our few remaining 
> > page flags?  We'll be in a mess when we run out.
> 
> well AFAICS the shortage really mostly affects 32-bit platforms. And 
> there we've got 19 bits used, out of 23 available, right?

Unfortunately the answer to that question is surprisingly hard to generate
and it probably has changed over time.  Christoph sat down and worked it
all out a few months ago.

One surprising problem is ia64 which uses (or used to use?) basically all
of the upper 32-bits.

> whether we track a page or not is rather fundamental to kmemcheck, i 
> dont see any easy way to get rid of that usage. (and since kmemcheck is 
> a transparent add-on, i dont see any obvious other candidate like 
> page->private either - all those fields might be utilized)

oooh yeah.  We've squeezed blood out of the pageframe.

> if we run out of that in the future: the high bits get used by sparse 
> section and numa node ID bits, worst-case we could live with restricting 
> the max number of NUMA nodes on 32-bit from 64 to 32? [NUMA on 32-bit is 
> an afterthought anyway.]

Yes, I think it's only NUMAQ and one of the old IBM machines.  I don't
think numaq ever went beyond 8 nodes.  superh is (or will) use NUMA, but
surely not with many nodes.

> Or we could do a CONFIG_KMEMCHECK=y only 
> page->flags_debug.

Yes, that'd be OK.   We could do that now, or just pop a comment in there.

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-16 20:50 ` Andi Kleen
@ 2008-04-17 10:06   ` Alexander van Heukelum
  2008-04-17 10:51     ` Andi Kleen
  2008-04-18  8:38     ` Ingo Molnar
  0 siblings, 2 replies; 71+ messages in thread
From: Alexander van Heukelum @ 2008-04-17 10:06 UTC (permalink / raw)
  To: Andi Kleen, Ingo Molnar; +Cc: linux-kernel


On Wed, 16 Apr 2008 22:50:51 +0200, "Andi Kleen" <andi@firstfloor.org>
said:
> Ingo Molnar <mingo@elte.hu> writes:
> 
> >  - generalized bitops - they are faster and smaller.
> 
> Faster in a 100% bogus benchmark with the most unrealistic input data
> set one can imagine with some effort. They might be faster or they
> might be slower, nobody really knows currently.

Hello Andi, Ingo,

The input for the first 'benchmark' was indeed completely unrealistic.
They did show a very convincing speedup, though. This program was
really written to verify the implementation and was later converted
to a benchmark. Many benchmarks are unrealistic. I also wrote a
benchmark for find_first_bit and find_next_bit:
        http://heukelum.fastmail.fm/find_first_bit

My conclusion would be: the speed of the generic bitmap implementation
is either better than or at least comparable to the current private
implementations in i386/x86_64. The generic version is out-of-line,
while the private implementation of i386 was inlined: this causes a
regression for very small bitmaps. However, if the bitmap size is
a constant and fits a long integer, the updated generic code should
inline an optimized version, like x86_64 currently does it.

I think the change is a good one.

Greetings,
    Alexander
-- 
  Alexander van Heukelum
  heukelum@fastmail.fm

-- 
http://www.fastmail.fm - The professional email service


^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17  9:36             ` Andrew Morton
  2008-04-17  9:46               ` Ingo Molnar
@ 2008-04-17 10:11               ` Andi Kleen
  2008-04-17 10:18                 ` Andrew Morton
  2008-04-17 10:19               ` Pekka Enberg
  2008-04-17 18:47               ` Vegard Nossum
  3 siblings, 1 reply; 71+ messages in thread
From: Andi Kleen @ 2008-04-17 10:11 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Ingo Molnar, linux-kernel, Linus Torvalds, Thomas Gleixner,
	H. Peter Anvin

Andrew Morton <akpm@linux-foundation.org> writes:
>
> Does it really really really need to consume one of our few remaining page
> flags?  We'll be in a mess when we run out.

No we're not. Just the (imho always misguided) "encode zone/node number 
into flags" optimization has to be removed again or made 64bit only.
Then there will be plenty of flags again.

Really I see no real reason this can't be done with a small hash table
again like x86-64 originally did.

-Andi

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17 10:11               ` Andi Kleen
@ 2008-04-17 10:18                 ` Andrew Morton
  2008-04-17 10:29                   ` Andi Kleen
  0 siblings, 1 reply; 71+ messages in thread
From: Andrew Morton @ 2008-04-17 10:18 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Ingo Molnar, linux-kernel, Linus Torvalds, Thomas Gleixner,
	H. Peter Anvin

On Thu, 17 Apr 2008 12:11:36 +0200 Andi Kleen <andi@firstfloor.org> wrote:

> Andrew Morton <akpm@linux-foundation.org> writes:
> >
> > Does it really really really need to consume one of our few remaining page
> > flags?  We'll be in a mess when we run out.
> 
> No we're not. Just the (imho always misguided) "encode zone/node number 
> into flags" optimization has to be removed again or made 64bit only.
> Then there will be plenty of flags again.

hm.  Or we add a new nid&zone field to the pageframe for 32bit NUMA.  Just
don't tell Paul Mundt ;)

Need to work out what's going on with ia64's use of the upper 32 bits too. 
I have a feeling it's using less than it used too but at 3AM I can't be
assed working it out.

> Really I see no real reason this can't be done with a small hash table
> again like x86-64 originally did.

How did that work?  A pfn->zone-id hash table would be huge?

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17  9:36             ` Andrew Morton
  2008-04-17  9:46               ` Ingo Molnar
  2008-04-17 10:11               ` Andi Kleen
@ 2008-04-17 10:19               ` Pekka Enberg
  2008-04-17 10:33                 ` Andrew Morton
  2008-04-17 18:47               ` Vegard Nossum
  3 siblings, 1 reply; 71+ messages in thread
From: Pekka Enberg @ 2008-04-17 10:19 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Ingo Molnar, linux-kernel, Linus Torvalds, Thomas Gleixner,
	H. Peter Anvin, Vegard Nossum

On Thu, Apr 17, 2008 at 12:36 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> > you mean kmemcheck? Yes, that's planned. We've been working 4 months
> > non-stop on kmemcheck to make it mergeable and usable, it's at version 7
> > right now, and it caught a handful of real bugs already (such as
> > 63a7138671c - unfortunately not credited in the log to kmemcheck). But
> > because it touches SLUB (because it has to - and they are acked by
> > Pekka) i never had the chance to move it into the for-akpm branch.
>
>  Does it really really really need to consume one of our few remaining page
>  flags?  We'll be in a mess when we run out.

FYI, the initial version of kmemcheck didn't have a separate page flag
(it abused SLUB internals) but it got really hairy and I think I
finally convinced Vegard to switch over to page flags after some
hair-pulling when we hit a bug. So yes, from SLUB maintainer point of
view, we _really, really_ want to use a page flag here.

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17 10:18                 ` Andrew Morton
@ 2008-04-17 10:29                   ` Andi Kleen
  0 siblings, 0 replies; 71+ messages in thread
From: Andi Kleen @ 2008-04-17 10:29 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Ingo Molnar, linux-kernel, Linus Torvalds, Thomas Gleixner,
	H. Peter Anvin

Andrew Morton wrote:
> On Thu, 17 Apr 2008 12:11:36 +0200 Andi Kleen <andi@firstfloor.org> wrote:
> 
>> Andrew Morton <akpm@linux-foundation.org> writes:
>>> Does it really really really need to consume one of our few remaining page
>>> flags?  We'll be in a mess when we run out.
>> No we're not. Just the (imho always misguided) "encode zone/node number 
>> into flags" optimization has to be removed again or made 64bit only.
>> Then there will be plenty of flags again.
> 
> hm.  Or we add a new nid&zone field to the pageframe for 32bit NUMA.  Just
> don't tell Paul Mundt ;)

Most (all?) NUMA archs have some way to get from phys->nid. Getting from
pfn->nid is then easy.

Originally this was all optimized for text size when this stuff was
still inlined, but at some point they were all out of lined anyways
(unless on FLAT iirc) so a lot of the old design decisions became obsolete.

BTW I should disclose that my mask allocator that I'm still planning
to push needs one flag bit on 32/64bit and another one on 64bit
(for swiotlb)

> 
> Need to work out what's going on with ia64's use of the upper 32 bits too. 
> I have a feeling it's using less than it used too but at 3AM I can't be
> assed working it out.
> 
>> Really I see no real reason this can't be done with a small hash table
>> again like x86-64 originally did.
> 
> How did that work?  A pfn->zone-id hash table would be huge?

Sorry i meant it used the hash table to look up the node. In fact
that code is still in there, although used less because a lot of these
lookups are resolved from the flags.

Once you have the node from the pfn it is a at most three range checks
to get to the zone (usually less). The most efficient way to do that is
to just open code it in code.

-Andi


^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17  8:14   ` Andrew Morton
  2008-04-17  8:57     ` Avi Kivity
@ 2008-04-17 10:32     ` Johannes Weiner
  2008-04-17 10:50       ` Andrew Morton
  2008-04-17 11:49     ` Christoph Hellwig
  2 siblings, 1 reply; 71+ messages in thread
From: Johannes Weiner @ 2008-04-17 10:32 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Ingo Molnar, linux-kernel, Linus Torvalds

Hi,

Andrew Morton <akpm@linux-foundation.org> writes:

> - extensive damage to the page-flags patches
>
>   Did you check that all architectures and configurations still have
>   sufficient page flags for us to be able to consume another one for
>   kmemcheck?  The MM developers have put much, much effort into avoiding
>   running out of flags over numerous years and afaik none of them even know
>   that this debug feature is using one of the few remaining ones.
>
>   What do we do when we run out?

Would it be feasible to add another unsigned long to struct page?  I
mean, extending such a common structure always sucks, but for
emergency...

#define PageFoobar(page)	test_bit(PG_foobar, &(page)->flags2)

Of course the essential core flags should always be in ->flags but
perhaps we could have a symbol CONFIG_NEED_EXTRA_PAGE_FLAGS that gets
selected by kmemcheck (and other candidates that are unlikely to be
enabled most of the time) and then #ifndef ->flags2 out.

	Hannes

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17 10:19               ` Pekka Enberg
@ 2008-04-17 10:33                 ` Andrew Morton
  2008-04-17 10:38                   ` Ingo Molnar
  2008-04-17 10:41                   ` Pekka Enberg
  0 siblings, 2 replies; 71+ messages in thread
From: Andrew Morton @ 2008-04-17 10:33 UTC (permalink / raw)
  To: Pekka Enberg
  Cc: Ingo Molnar, linux-kernel, Linus Torvalds, Thomas Gleixner,
	H. Peter Anvin, Vegard Nossum

On Thu, 17 Apr 2008 13:19:32 +0300 "Pekka Enberg" <penberg@cs.helsinki.fi> wrote:

> On Thu, Apr 17, 2008 at 12:36 PM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
> > > you mean kmemcheck? Yes, that's planned. We've been working 4 months
> > > non-stop on kmemcheck to make it mergeable and usable, it's at version 7
> > > right now, and it caught a handful of real bugs already (such as
> > > 63a7138671c - unfortunately not credited in the log to kmemcheck). But
> > > because it touches SLUB (because it has to - and they are acked by
> > > Pekka) i never had the chance to move it into the for-akpm branch.
> >
> >  Does it really really really need to consume one of our few remaining page
> >  flags?  We'll be in a mess when we run out.
> 
> FYI, the initial version of kmemcheck didn't have a separate page flag
> (it abused SLUB internals) but it got really hairy and I think I
> finally convinced Vegard to switch over to page flags after some
> hair-pulling when we hit a bug. So yes, from SLUB maintainer point of
> view, we _really, really_ want to use a page flag here.

Thank you whoever wrote kmemcheck.txt

How come slub uses one byte to track the status of each byte when it could
use a single bit?

We (still!) have not made the decision whether to proceed with slab or
slub.  How hard would it be to port kmemcheck into slab?


^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17 10:33                 ` Andrew Morton
@ 2008-04-17 10:38                   ` Ingo Molnar
  2008-04-17 10:42                     ` Pekka Enberg
  2008-04-17 14:01                     ` Arjan van de Ven
  2008-04-17 10:41                   ` Pekka Enberg
  1 sibling, 2 replies; 71+ messages in thread
From: Ingo Molnar @ 2008-04-17 10:38 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Pekka Enberg, linux-kernel, Linus Torvalds, Thomas Gleixner,
	H. Peter Anvin, Vegard Nossum


* Andrew Morton <akpm@linux-foundation.org> wrote:

> Thank you whoever wrote kmemcheck.txt
> 
> How come slub uses one byte to track the status of each byte when it 
> could use a single bit?
> 
> We (still!) have not made the decision whether to proceed with slab or 
> slub.  How hard would it be to port kmemcheck into slab?

i think slab is clearly out, unless some catastrophic regression is 
found. But Nick's SLQB might replace SLUB ;-)

	Ingo

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17 10:33                 ` Andrew Morton
  2008-04-17 10:38                   ` Ingo Molnar
@ 2008-04-17 10:41                   ` Pekka Enberg
  1 sibling, 0 replies; 71+ messages in thread
From: Pekka Enberg @ 2008-04-17 10:41 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Ingo Molnar, linux-kernel, Linus Torvalds, Thomas Gleixner,
	H. Peter Anvin, Vegard Nossum

Hi Andrew,

On Thu, Apr 17, 2008 at 1:33 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
>  Thank you whoever wrote kmemcheck.txt

That would be Vegard.

On Thu, Apr 17, 2008 at 1:33 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
>  How come slub uses one byte to track the status of each byte when it could
>  use a single bit?

Single bit is not enough as we track use after free as well (after
we've added delayed freeing to the beast).

On Thu, Apr 17, 2008 at 1:33 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
>  We (still!) have not made the decision whether to proceed with slab or
>  slub.  How hard would it be to port kmemcheck into slab?

Not hard.

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17 10:38                   ` Ingo Molnar
@ 2008-04-17 10:42                     ` Pekka Enberg
  2008-04-18 11:12                       ` Nick Piggin
  2008-04-17 14:01                     ` Arjan van de Ven
  1 sibling, 1 reply; 71+ messages in thread
From: Pekka Enberg @ 2008-04-17 10:42 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Andrew Morton, linux-kernel, Linus Torvalds, Thomas Gleixner,
	H. Peter Anvin, Vegard Nossum, Nick Piggin

On Thu, Apr 17, 2008 at 1:38 PM, Ingo Molnar <mingo@elte.hu> wrote:
>  > We (still!) have not made the decision whether to proceed with slab or
>  > slub.  How hard would it be to port kmemcheck into slab?
>
>  i think slab is clearly out, unless some catastrophic regression is
>  found. But Nick's SLQB might replace SLUB ;-)

Hey, we all have our favorite replacements for kmalloc():

http://www.kernel.org/pub/linux/kernel/people/penberg/patches/binalloc/2.6.25-rc8/kmalloc-binning

But it seems unrealistic to expect any of them to replace SLUB or SLAB
in the near future.

                             Pekka

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17 10:32     ` Johannes Weiner
@ 2008-04-17 10:50       ` Andrew Morton
  0 siblings, 0 replies; 71+ messages in thread
From: Andrew Morton @ 2008-04-17 10:50 UTC (permalink / raw)
  To: Johannes Weiner; +Cc: Ingo Molnar, linux-kernel, Linus Torvalds

On Thu, 17 Apr 2008 12:32:03 +0200 Johannes Weiner <hannes@saeurebad.de> wrote:

> Hi,
> 
> Andrew Morton <akpm@linux-foundation.org> writes:
> 
> > - extensive damage to the page-flags patches
> >
> >   Did you check that all architectures and configurations still have
> >   sufficient page flags for us to be able to consume another one for
> >   kmemcheck?  The MM developers have put much, much effort into avoiding
> >   running out of flags over numerous years and afaik none of them even know
> >   that this debug feature is using one of the few remaining ones.
> >
> >   What do we do when we run out?
> 
> Would it be feasible to add another unsigned long to struct page?  I
> mean, extending such a common structure always sucks, but for
> emergency...
> 
> #define PageFoobar(page)	test_bit(PG_foobar, &(page)->flags2)
> 
> Of course the essential core flags should always be in ->flags but
> perhaps we could have a symbol CONFIG_NEED_EXTRA_PAGE_FLAGS that gets
> selected by kmemcheck (and other candidates that are unlikely to be
> enabled most of the time) and then #ifndef ->flags2 out.
> 

Yes, but I think that only applies to PG_tracked.

We may be able to reclaim PG_buddy by putting various fields in the
pageframe to idiotic otherwise-cant-happen states.  Like

static inline bool PageBuddy(struct page *page)
{
	return page->mapping == (long)&page->private;
}

or something.  But these things are so overloaded it gets tricky.

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17 10:06   ` Alexander van Heukelum
@ 2008-04-17 10:51     ` Andi Kleen
  2008-04-17 13:33       ` Alexander van Heukelum
  2008-04-18  8:38     ` Ingo Molnar
  1 sibling, 1 reply; 71+ messages in thread
From: Andi Kleen @ 2008-04-17 10:51 UTC (permalink / raw)
  To: Alexander van Heukelum; +Cc: Ingo Molnar, linux-kernel


> 
> The input for the first 'benchmark' was indeed completely unrealistic.
> They did show a very convincing speedup, though. This program was
> really written to verify the implementation and was later converted
> to a benchmark. Many benchmarks are unrealistic. I also wrote a
> benchmark for find_first_bit and find_next_bit:
>         http://heukelum.fastmail.fm/find_first_bit

I think a realistic benchmark would be by running a real kernel
and profiling the input values of the bitmap functions and then
testing these cases.

I actually started that when I complained last time by writing
a systemtap script for this that generates a histogram, but for some
reason systemtap couldn't tap all bitmap functions in my kernel and
missed some completely and I ran out of time tracking that down.

My gut feeling is the only interesting cases are cpumask/nodemask sized
(which can be one word, two words but now upto 8 words on a NR_CPU=4096
x86 kernel) and then 4k sized ext3/reiser/etc. block bitmaps.

> My conclusion would be: the speed of the generic bitmap implementation
> is either better than or at least comparable to the current private
> implementations in i386/x86_64. 

Ok.

The generic version is out-of-line,
> while the private implementation of i386 was inlined: this causes a
> regression for very small bitmaps. However, if the bitmap size is
> a constant and fits a long integer, the updated generic code should
> inline an optimized version, like x86_64 currently does it.

Yes it should probably. cpumask walks are relatively common.

I remember profiling mysql some time ago which did bad overscheduling
due to dumb locking. Funny was that the mask walking in the scheduler
actually stood out. No, i don't claim extreme overscheduling is an
interesting case to optimize for, but then there are more realistic
workloads which also do a lot of context switching.

BTW if you do generic work on this: one reason the generated code for
for_each_cpu etc. is so ugly is that the code has checks for
find_next_bit returning >= max size. If you can generize the
code enough to make sure no arch does that anymore these checks
could be eliminated.

-Andi

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17  8:42           ` Andrew Morton
@ 2008-04-17 11:49             ` Christoph Hellwig
  2008-04-17 11:56               ` Ingo Molnar
  2008-04-17 18:01               ` Andrew Morton
  0 siblings, 2 replies; 71+ messages in thread
From: Christoph Hellwig @ 2008-04-17 11:49 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Pekka Enberg, Ingo Molnar, linux-kernel, Linus Torvalds

On Thu, Apr 17, 2008 at 01:42:17AM -0700, Andrew Morton wrote:
> Apparently that code is not being proposed for merge and it all got
> reimplemented and moved elsewhere.  I knew nothing of this.

It's not just you, I haven't heard anythinh either :)  I'm also still
not comfortable with adding another quick-hacker interface instead of
making sure the existing one doesn't suck.


^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17  8:14   ` Andrew Morton
  2008-04-17  8:57     ` Avi Kivity
  2008-04-17 10:32     ` Johannes Weiner
@ 2008-04-17 11:49     ` Christoph Hellwig
  2008-04-17 17:36       ` Andrew Morton
  2 siblings, 1 reply; 71+ messages in thread
From: Christoph Hellwig @ 2008-04-17 11:49 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Ingo Molnar, linux-kernel, Linus Torvalds

On Thu, Apr 17, 2008 at 01:14:01AM -0700, Andrew Morton wrote:
> - several rejects in
>   x86-olpc-add-one-laptop-per-child-architecture-support.patch

Did this ever got posted publically somewhere?


^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17 11:49             ` Christoph Hellwig
@ 2008-04-17 11:56               ` Ingo Molnar
  2008-04-17 18:01               ` Andrew Morton
  1 sibling, 0 replies; 71+ messages in thread
From: Ingo Molnar @ 2008-04-17 11:56 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Andrew Morton, Pekka Enberg, linux-kernel, Linus Torvalds


* Christoph Hellwig <hch@infradead.org> wrote:

> On Thu, Apr 17, 2008 at 01:42:17AM -0700, Andrew Morton wrote:
> > Apparently that code is not being proposed for merge and it all got
> > reimplemented and moved elsewhere.  I knew nothing of this.
> 
> It's not just you, I haven't heard anythinh either :) I'm also still 
> not comfortable with adding another quick-hacker interface instead of 
> making sure the existing one doesn't suck.

it's all in debugfs so no stable interface worries. Not much has changed 
since we last posted it to lkml. Posting the full patchset is 
impractical as it's in excess of 100 commits (but we did post various 
versions of it) - you can pick up the latest from:

   http://people.redhat.com/mingo/sched-devel.git/README

check out kernel/trace/. Usage: check out 
/sys/kernel/debug/tracing/README :-)

	Ingo

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17 10:51     ` Andi Kleen
@ 2008-04-17 13:33       ` Alexander van Heukelum
  0 siblings, 0 replies; 71+ messages in thread
From: Alexander van Heukelum @ 2008-04-17 13:33 UTC (permalink / raw)
  To: Andi Kleen; +Cc: Ingo Molnar, linux-kernel

On Thu, 17 Apr 2008 12:51:09 +0200, "Andi Kleen" <andi@firstfloor.org>
said:
> I think a realistic benchmark would be by running a real kernel
> and profiling the input values of the bitmap functions and then
> testing these cases.
> 
> I actually started that when I complained last time by writing
> a systemtap script for this that generates a histogram, but for some
> reason systemtap couldn't tap all bitmap functions in my kernel and
> missed some completely and I ran out of time tracking that down.
> 
> My gut feeling is the only interesting cases are cpumask/nodemask sized
> (which can be one word, two words but now upto 8 words on a NR_CPU=4096
> x86 kernel) and then 4k sized ext3/reiser/etc. block bitmaps.
>
> The generic version is out-of-line,
> > while the private implementation of i386 was inlined: this causes a
> > regression for very small bitmaps. However, if the bitmap size is
> > a constant and fits a long integer, the updated generic code should
> > inline an optimized version, like x86_64 currently does it.
> 
> Yes it should probably. cpumask walks are relatively common.

Hi,

The version that is in x86#testing _will_ do this optimization. For
32 node SMP on x86_64 this results in:

<__first_cpu>:
    mov    $0x20,%edx   (inlined...)
    mov    $0x100000000,%rax
    or     (%rdi),%rax
    bsf    %rax,%rax    (... find_first_bit)
    cmp    $0x20,%eax   (superfluous paranoia...)
    cmovg  %edx,%eax    (... for broken find_first_bit)
    retq   

and something similar for __next_cpu.

> I remember profiling mysql some time ago which did bad overscheduling
> due to dumb locking. Funny was that the mask walking in the scheduler
> actually stood out. No, i don't claim extreme overscheduling is an
> interesting case to optimize for, but then there are more realistic
> workloads which also do a lot of context switching.
> 
> BTW if you do generic work on this: one reason the generated code for
> for_each_cpu etc. is so ugly is that the code has checks for
> find_next_bit returning >= max size. If you can generize the
> code enough to make sure no arch does that anymore these checks
> could be eliminated.

for_each_cpu code looks fine:

    mov    $cpumapaddress,%rdi
    callq  <__first_cpu>
    jmp    end_of_body
start_of_body:
    ...
end_of_body:
    mov    $cpumapaddress,%edi  ($mapaddress often cached in register)
    callq  <__next_cpu>
    cmp    $0x1f,%eax
    jle    start_of_body

On the other hand it would be nice to change __first_cpu and
__next_cpu into inline functions. If all implementations of
find_first_bit and find_next_bit would reliably return max_size
if no bits were found, that would be a good thing to do. The
generic one does return max_size.

Greetings,
    Alexander

> -Andi
-- 
  Alexander van Heukelum
  heukelum@fastmail.fm

-- 
http://www.fastmail.fm - One of many happy users:
  http://www.fastmail.fm/docs/quotes.html


^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17 10:38                   ` Ingo Molnar
  2008-04-17 10:42                     ` Pekka Enberg
@ 2008-04-17 14:01                     ` Arjan van de Ven
  2008-04-17 15:26                       ` Ingo Molnar
  2008-04-18 12:41                       ` Ingo Molnar
  1 sibling, 2 replies; 71+ messages in thread
From: Arjan van de Ven @ 2008-04-17 14:01 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Andrew Morton, Pekka Enberg, linux-kernel, Linus Torvalds,
	Thomas Gleixner, H. Peter Anvin, Vegard Nossum

On Thu, 17 Apr 2008 12:38:00 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > Thank you whoever wrote kmemcheck.txt
> > 
> > How come slub uses one byte to track the status of each byte when
> > it could use a single bit?
> > 
> > We (still!) have not made the decision whether to proceed with slab
> > or slub.  How hard would it be to port kmemcheck into slab?
> 
> i think slab is clearly out, unless some catastrophic regression is 
> found. 

SLUB still has that several percent TPC-C regression....
Christoph has a small reproducer testcase.


-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17 14:01                     ` Arjan van de Ven
@ 2008-04-17 15:26                       ` Ingo Molnar
  2008-04-18 12:41                       ` Ingo Molnar
  1 sibling, 0 replies; 71+ messages in thread
From: Ingo Molnar @ 2008-04-17 15:26 UTC (permalink / raw)
  To: Arjan van de Ven
  Cc: Andrew Morton, Pekka Enberg, linux-kernel, Linus Torvalds,
	Thomas Gleixner, H. Peter Anvin, Vegard Nossum


* Arjan van de Ven <arjan@infradead.org> wrote:

> > > We (still!) have not made the decision whether to proceed with 
> > > slab or slub.  How hard would it be to port kmemcheck into slab?
> > 
> > i think slab is clearly out, unless some catastrophic regression is 
> > found.
> 
> SLUB still has that several percent TPC-C regression.... Christoph has 
> a small reproducer testcase.

any URL to that small reproducer testcase?

	Ingo

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17 11:49     ` Christoph Hellwig
@ 2008-04-17 17:36       ` Andrew Morton
  0 siblings, 0 replies; 71+ messages in thread
From: Andrew Morton @ 2008-04-17 17:36 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: Ingo Molnar, linux-kernel, Linus Torvalds

On Thu, 17 Apr 2008 07:49:55 -0400 Christoph Hellwig <hch@infradead.org> wrote:

> On Thu, Apr 17, 2008 at 01:14:01AM -0700, Andrew Morton wrote:
> > - several rejects in
> >   x86-olpc-add-one-laptop-per-child-architecture-support.patch
> 
> Did this ever got posted publically somewhere?

People will sometimes send me offlist patches and I'll usually notice it and
will always ask them not to, often requesting a resend.  This one was on
lkml, subject "[PATCH 3/3] OLPC: add One Laptop Per Child architecture
support"

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17 11:49             ` Christoph Hellwig
  2008-04-17 11:56               ` Ingo Molnar
@ 2008-04-17 18:01               ` Andrew Morton
  2008-04-17 18:51                 ` Ingo Molnar
  1 sibling, 1 reply; 71+ messages in thread
From: Andrew Morton @ 2008-04-17 18:01 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: Pekka Enberg, Ingo Molnar, linux-kernel, Linus Torvalds

On Thu, 17 Apr 2008 07:49:00 -0400 Christoph Hellwig <hch@infradead.org> wrote:

> On Thu, Apr 17, 2008 at 01:42:17AM -0700, Andrew Morton wrote:
> > Apparently that code is not being proposed for merge and it all got
> > reimplemented and moved elsewhere.  I knew nothing of this.
> 
> It's not just you, I haven't heard anythinh either :)  I'm also still
> not comfortable with adding another quick-hacker interface instead of
> making sure the existing one doesn't suck.

afaik the sysprof-vs-oprofile issue still hasn't been settled.  Maybe it's
no longer a relevant question with the new code - I just don't know. 
Everything went all quiet and then this stuff happened.

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17  9:36             ` Andrew Morton
                                 ` (2 preceding siblings ...)
  2008-04-17 10:19               ` Pekka Enberg
@ 2008-04-17 18:47               ` Vegard Nossum
  2008-04-17 19:27                 ` Ingo Molnar
  2008-04-17 19:43                 ` Andrew Morton
  3 siblings, 2 replies; 71+ messages in thread
From: Vegard Nossum @ 2008-04-17 18:47 UTC (permalink / raw)
  To: Ingo Molnar, Andrew Morton
  Cc: linux-kernel, Linus Torvalds, Thomas Gleixner, H. Peter Anvin

[-- Attachment #1: Type: text/plain, Size: 1896 bytes --]

On Thu, Apr 17, 2008 at 11:36 AM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Thu, 17 Apr 2008 11:30:25 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>  > you mean kmemcheck? Yes, that's planned. We've been working 4 months
>  > non-stop on kmemcheck to make it mergeable and usable, it's at version 7
>  > right now, and it caught a handful of real bugs already (such as
>  > 63a7138671c - unfortunately not credited in the log to kmemcheck). But
>  > because it touches SLUB (because it has to - and they are acked by
>  > Pekka) i never had the chance to move it into the for-akpm branch.
>
>  Does it really really really need to consume one of our few remaining page
>  flags?  We'll be in a mess when we run out.

Actually it doesn't. I attach a patch which gets rid of the page flag,
and we rely instead on the PTE flag for page-trackedness.

The reason we didn't do this at once is that the making of kmemcheck
has been pretty much my first introduction to SLUB, x86, page flags,
etc., and the actual semantics of the various introduced flags have
varied since the first version of kmemcheck. At this point, the struct
page flags weren't actually needed anymore, but they were convenient.

My apologies for not inlining the patch -- I don't have a mail client
that won't mess up whitespace. It can also be downloaded at:
http://folk.uio.no/vegardno/linux/0001-kmemcheck-remove-use-of-tracked-page-flag.patch

The patch has received minimal amount of testing, but I've
double-checked the logic. It boots fine on my laptop, boot log at:
http://folk.uio.no/vegardno/linux/kmemcheck-20080417.txt

Ingo, will you take this for some additional testing?


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-kmemcheck-remove-use-of-tracked-page-flag.patch --]
[-- Type: text/x-patch; name=0001-kmemcheck-remove-use-of-tracked-page-flag.patch, Size: 7036 bytes --]

From 9860cfa3a38f72b82a83024b765d2aab39a917e9 Mon Sep 17 00:00:00 2001
From: Vegard Nossum <vegard.nossum@gmail.com>
Date: Thu, 17 Apr 2008 19:53:48 +0200
Subject: [PATCH] kmemcheck: remove use of "tracked" page flag

This patch replaces the use of the PG_tracked page flag and rely instead
on the PTE flag PAGE_HIDDEN to determine whether a page is tracked.

Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com>
---
 arch/x86/kernel/kmemcheck.c |  105 +++++++++++++++++-------------------------
 include/linux/kmemcheck.h   |    2 +
 include/linux/page-flags.h  |    5 --
 mm/slub.c                   |    2 +-
 4 files changed, 46 insertions(+), 68 deletions(-)

diff --git a/arch/x86/kernel/kmemcheck.c b/arch/x86/kernel/kmemcheck.c
index 16dce10..d82f35d 100644
--- a/arch/x86/kernel/kmemcheck.c
+++ b/arch/x86/kernel/kmemcheck.c
@@ -233,12 +233,27 @@ param_kmemcheck(char *str)
 	if (!str)
 		return -EINVAL;
 
-	sscanf("%d", str, &kmemcheck_enabled);
+	sscanf(str, "%d", &kmemcheck_enabled);
 	return 0;
 }
 
 early_param("kmemcheck", param_kmemcheck);
 
+static pte_t *
+address_get_pte(unsigned int address)
+{
+	pte_t *pte;
+	int level;
+
+	pte = lookup_address(address, &level);
+	if (!pte)
+		return NULL;
+	if (!pte_hidden(*pte))
+		return NULL;
+
+	return pte;
+}
+
 /*
  * Return the shadow address for the given address. Returns NULL if the
  * address is not tracked.
@@ -249,88 +264,53 @@ early_param("kmemcheck", param_kmemcheck);
 static void *
 address_get_shadow(unsigned long address)
 {
+	pte_t *pte;
 	struct page *page;
 	struct page *head;
 
 	if (!virt_addr_valid(address))
 		return NULL;
 
+	pte = address_get_pte(address);
+	if (!pte)
+		return NULL;
+
 	/* The accessed page */
 	page = virt_to_page(address);
-	if (!PageCompound(page))
-		return NULL;
+	BUG_ON(!PageCompound(page));
 
 	/* The head page */
 	head = compound_head(page);
-	if (!PageTracked(head))
-		return NULL;
+	BUG_ON(compound_order(head) == 0);
 
 	return (void *) address + (PAGE_SIZE << (compound_order(head) - 1));
 }
 
 static int
-show_addr(uint32_t addr)
+show_addr(uint32_t address)
 {
 	pte_t *pte;
-	int level;
-
-	if (!address_get_shadow(addr))
-		return 0;
-
-	pte = lookup_address(addr, &level);
-	BUG_ON(!pte);
-
-	if (level != PG_LEVEL_4K)
-		return 0;
-
-	set_pte(pte, __pte(pte_val(*pte) | _PAGE_PRESENT));
-	__flush_tlb_one(addr);
-	return 1;
-}
 
-/*
- * In case there's something seriously wrong with kmemcheck (like a recursive
- * or looping page fault), we should disable tracking for the page as a last
- * attempt to not hang the machine.
- */
-static void
-emergency_show_addr(uint32_t address)
-{
-	pte_t *pte;
-	int level;
-
-	pte = lookup_address(address, &level);
+	pte = address_get_pte(address);
 	if (!pte)
-		return;
-	if (level != PG_LEVEL_4K)
-		return;
-
-	/* Don't change pages that weren't hidden in the first place -- they
-	 * aren't ours to modify. */
-	if (!(pte_val(*pte) & _PAGE_HIDDEN))
-		return;
+		return 0;
 
 	set_pte(pte, __pte(pte_val(*pte) | _PAGE_PRESENT));
 	__flush_tlb_one(address);
+	return 1;
 }
 
 static int
-hide_addr(uint32_t addr)
+hide_addr(uint32_t address)
 {
 	pte_t *pte;
-	int level;
-
-	if (!address_get_shadow(addr))
-		return 0;
 
-	pte = lookup_address(addr, &level);
-	BUG_ON(!pte);
-
-	if (level != PG_LEVEL_4K)
+	pte = address_get_pte(address);
+	if (!pte)
 		return 0;
 
 	set_pte(pte, __pte(pte_val(*pte) & ~_PAGE_PRESENT));
-	__flush_tlb_one(addr);
+	__flush_tlb_one(address);
 	return 1;
 }
 
@@ -365,8 +345,8 @@ kmemcheck_show(struct pt_regs *regs)
 	BUG_ON(!irqs_disabled());
 
 	if (unlikely(data->balance != 0)) {
-		emergency_show_addr(data->addr1);
-		emergency_show_addr(data->addr2);
+		show_addr(data->addr1);
+		show_addr(data->addr2);
 		error_save_bug(regs);
 		data->balance = 0;
 		return;
@@ -414,8 +394,8 @@ kmemcheck_hide(struct pt_regs *regs)
 		return;
 
 	if (unlikely(data->balance != 1)) {
-		emergency_show_addr(data->addr1);
-		emergency_show_addr(data->addr2);
+		show_addr(data->addr1);
+		show_addr(data->addr2);
 		error_save_bug(regs);
 		data->addr1 = 0;
 		data->addr2 = 0;
@@ -456,9 +436,6 @@ kmemcheck_show_pages(struct page *p, unsigned int n)
 {
 	unsigned int i;
 
-	BUG_ON(!PageCompound(p));
-	ClearPageTracked(compound_head(p));
-
 	for (i = 0; i < n; ++i) {
 		unsigned long address;
 		pte_t *pte;
@@ -477,14 +454,18 @@ kmemcheck_show_pages(struct page *p, unsigned int n)
 	}
 }
 
+bool
+kmemcheck_page_is_tracked(struct page *p)
+{
+	/* This will also check the "hidden" flag of the PTE. */
+	return address_get_pte((unsigned long) page_address(p));
+}
+
 void
 kmemcheck_hide_pages(struct page *p, unsigned int n)
 {
 	unsigned int i;
 
-	BUG_ON(!PageCompound(p));
-	SetPageTracked(compound_head(p));
-
 	for (i = 0; i < n; ++i) {
 		unsigned long address;
 		pte_t *pte;
@@ -762,7 +743,7 @@ kmemcheck_access(struct pt_regs *regs,
 
 	/* Recursive fault -- ouch. */
 	if (data->busy) {
-		emergency_show_addr(fallback_address);
+		show_addr(fallback_address);
 		error_save_bug(regs);
 		return;
 	}
diff --git a/include/linux/kmemcheck.h b/include/linux/kmemcheck.h
index 801da50..8d129eb 100644
--- a/include/linux/kmemcheck.h
+++ b/include/linux/kmemcheck.h
@@ -9,6 +9,8 @@ void kmemcheck_init(void);
 void kmemcheck_show_pages(struct page *p, unsigned int n);
 void kmemcheck_hide_pages(struct page *p, unsigned int n);
 
+bool kmemcheck_page_is_tracked(struct page *p);
+
 void kmemcheck_mark_unallocated(void *address, unsigned int n);
 void kmemcheck_mark_uninitialized(void *address, unsigned int n);
 void kmemcheck_mark_initialized(void *address, unsigned int n);
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index 63f5fd8..3696889 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -89,7 +89,6 @@
 #define PG_mappedtodisk		16	/* Has blocks allocated on-disk */
 #define PG_reclaim		17	/* To be reclaimed asap */
 #define PG_buddy		19	/* Page is free, on buddy lists */
-#define PG_tracked		20	/* Tracked by kmemcheck */
 
 /* PG_readahead is only used for file reads; PG_reclaim is only for writes */
 #define PG_readahead		PG_reclaim /* Reminder to do async read-ahead */
@@ -297,10 +296,6 @@ static inline void __ClearPageTail(struct page *page)
 #define SetPageUncached(page)	set_bit(PG_uncached, &(page)->flags)
 #define ClearPageUncached(page)	clear_bit(PG_uncached, &(page)->flags)
 
-#define PageTracked(page)	test_bit(PG_tracked, &(page)->flags)
-#define SetPageTracked(page)	set_bit(PG_tracked, &(page)->flags)
-#define ClearPageTracked(page)	clear_bit(PG_tracked, &(page)->flags)
-
 
 struct page;	/* forward declaration */
 
diff --git a/mm/slub.c b/mm/slub.c
index 9b58979..7a544e6 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1125,7 +1125,7 @@ static void __free_slab(struct kmem_cache *s, struct page *page)
 		ClearSlabDebug(page);
 	}
 
-	if (PageTracked(page) && !(s->flags & SLAB_NOTRACK)) {
+	if (kmemcheck_page_is_tracked(page) && !(s->flags & SLAB_NOTRACK)) {
 		kmemcheck_free_slab(s, page, pages);
 		return;
 	}
-- 
1.5.4.1


^ permalink raw reply related	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17 18:01               ` Andrew Morton
@ 2008-04-17 18:51                 ` Ingo Molnar
  2008-04-17 19:57                   ` Andrew Morton
  2008-04-18  9:33                   ` Tomasz Kłoczko
  0 siblings, 2 replies; 71+ messages in thread
From: Ingo Molnar @ 2008-04-17 18:51 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Christoph Hellwig, Pekka Enberg, linux-kernel, Linus Torvalds,
	Arjan van de Ven


* Andrew Morton <akpm@linux-foundation.org> wrote:

> afaik the sysprof-vs-oprofile issue still hasn't been settled.  Maybe 
> it's no longer a relevant question with the new code - I just don't 
> know. Everything went all quiet and then this stuff happened.

i dont think there's any big issue here. Sysprof is a time and stack 
system-wide tracer/profiler, oprofile profiles CPU events - deep 
stacktracing is an afterthought there. And how do you set up oprofile to 
do precise time events?

with sysprof you can do:

  cd /sys/kernel/debug/tracing
  echo sysprof > current_tracer
  cat trace_pipe

and you'll see the trace events go by, live. The user-space bits of 
sysprof have been ported over to ftrace/sysprof already and it's a 
really nice tool that shows a deep stack-trace based hierarchical 
"vertical" profile instead of the usual finegrained profile.

It certainly helps that the author of the tracer plugin (Soeren 
Sandmann) is the author of the userspace app too - so there's a rather 
well-working feedback loop here ;-)

With oprofile all these things are rather indirect, the API is more 
complex, it forces per-CPU buffers, etc. etc. I think for 
instrumentation the driving force must be usability, and sysprof/ftrace 
is hands down more usable - to me at least.

	Ingo

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17 18:47               ` Vegard Nossum
@ 2008-04-17 19:27                 ` Ingo Molnar
  2008-04-17 19:35                   ` Ingo Molnar
  2008-04-17 19:43                 ` Andrew Morton
  1 sibling, 1 reply; 71+ messages in thread
From: Ingo Molnar @ 2008-04-17 19:27 UTC (permalink / raw)
  To: Vegard Nossum
  Cc: Andrew Morton, linux-kernel, Linus Torvalds, Thomas Gleixner,
	H. Peter Anvin


* Vegard Nossum <vegard.nossum@gmail.com> wrote:

> >  Does it really really really need to consume one of our few remaining page
> >  flags?  We'll be in a mess when we run out.
> 
> Actually it doesn't. I attach a patch which gets rid of the page flag, 
> and we rely instead on the PTE flag for page-trackedness.
[...]
> Ingo, will you take this for some additional testing?

thanks Vegard, i've applied it - looks good to me too.

	Ingo

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17 19:27                 ` Ingo Molnar
@ 2008-04-17 19:35                   ` Ingo Molnar
  2008-04-17 19:39                     ` Vegard Nossum
  0 siblings, 1 reply; 71+ messages in thread
From: Ingo Molnar @ 2008-04-17 19:35 UTC (permalink / raw)
  To: Vegard Nossum
  Cc: Andrew Morton, linux-kernel, Linus Torvalds, Thomas Gleixner,
	H. Peter Anvin


* Ingo Molnar <mingo@elte.hu> wrote:

> > Actually it doesn't. I attach a patch which gets rid of the page flag, 
> > and we rely instead on the PTE flag for page-trackedness.
> [...]
> > Ingo, will you take this for some additional testing?
> 
> thanks Vegard, i've applied it - looks good to me too.

x86.git randconfig testing found a build bug - fix below.

	Ingo

------------>
Subject: kmemcheck: fix build
From: Ingo Molnar <mingo@elte.hu>
Date: Thu Apr 17 21:20:43 CEST 2008

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 include/linux/kmemcheck.h |    3 +++
 1 file changed, 3 insertions(+)

Index: linux/include/linux/kmemcheck.h
===================================================================
--- linux.orig/include/linux/kmemcheck.h
+++ linux/include/linux/kmemcheck.h
@@ -1,6 +1,8 @@
 #ifndef LINUX_KMEMCHECK_H
 #define LINUX_KMEMCHECK_H
 
+#include <linux/types.h>
+
 #ifdef CONFIG_KMEMCHECK
 extern int kmemcheck_enabled;
 
@@ -24,6 +26,7 @@ void kmemcheck_mark_uninitialized_pages(
 #ifndef CONFIG_KMEMCHECK
 #define kmemcheck_enabled 0
 static inline void kmemcheck_init(void) { }
+static inline bool kmemcheck_page_is_tracked(struct page *p) { return false; }
 #endif /* CONFIG_KMEMCHECK */
 
 #endif /* LINUX_KMEMCHECK_H */

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17 19:35                   ` Ingo Molnar
@ 2008-04-17 19:39                     ` Vegard Nossum
  0 siblings, 0 replies; 71+ messages in thread
From: Vegard Nossum @ 2008-04-17 19:39 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Andrew Morton, linux-kernel, Linus Torvalds, Thomas Gleixner,
	H. Peter Anvin

On Thu, Apr 17, 2008 at 9:35 PM, Ingo Molnar <mingo@elte.hu> wrote:
>
>  * Ingo Molnar <mingo@elte.hu> wrote:
>
>
> > > Actually it doesn't. I attach a patch which gets rid of the page flag,
>  > > and we rely instead on the PTE flag for page-trackedness.
>  > [...]
>  > > Ingo, will you take this for some additional testing?
>  >
>  > thanks Vegard, i've applied it - looks good to me too.
>
>  x86.git randconfig testing found a build bug - fix below.
>
>         Ingo
>

Oh, oops. Of course... Thanks, you shouldn't have had to do that :-(

Vegard

>  ------------>
>  Subject: kmemcheck: fix build
>  From: Ingo Molnar <mingo@elte.hu>
>  Date: Thu Apr 17 21:20:43 CEST 2008
>
>  Signed-off-by: Ingo Molnar <mingo@elte.hu>
>  ---
>   include/linux/kmemcheck.h |    3 +++
>   1 file changed, 3 insertions(+)
>
>  Index: linux/include/linux/kmemcheck.h
>  ===================================================================
>  --- linux.orig/include/linux/kmemcheck.h
>  +++ linux/include/linux/kmemcheck.h
>  @@ -1,6 +1,8 @@
>   #ifndef LINUX_KMEMCHECK_H
>   #define LINUX_KMEMCHECK_H
>
>  +#include <linux/types.h>
>  +
>   #ifdef CONFIG_KMEMCHECK
>   extern int kmemcheck_enabled;
>
>  @@ -24,6 +26,7 @@ void kmemcheck_mark_uninitialized_pages(
>   #ifndef CONFIG_KMEMCHECK
>   #define kmemcheck_enabled 0
>   static inline void kmemcheck_init(void) { }
>  +static inline bool kmemcheck_page_is_tracked(struct page *p) { return false; }
>   #endif /* CONFIG_KMEMCHECK */
>
>   #endif /* LINUX_KMEMCHECK_H */
>



-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17 18:47               ` Vegard Nossum
  2008-04-17 19:27                 ` Ingo Molnar
@ 2008-04-17 19:43                 ` Andrew Morton
  2008-04-17 20:39                   ` Vegard Nossum
  1 sibling, 1 reply; 71+ messages in thread
From: Andrew Morton @ 2008-04-17 19:43 UTC (permalink / raw)
  To: Vegard Nossum; +Cc: mingo, linux-kernel, torvalds, tglx, hpa

On Thu, 17 Apr 2008 20:47:06 +0200
"Vegard Nossum" <vegard.nossum@gmail.com> wrote:

> On Thu, Apr 17, 2008 at 11:36 AM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
> > On Thu, 17 Apr 2008 11:30:25 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> >  > you mean kmemcheck? Yes, that's planned. We've been working 4 months
> >  > non-stop on kmemcheck to make it mergeable and usable, it's at version 7
> >  > right now, and it caught a handful of real bugs already (such as
> >  > 63a7138671c - unfortunately not credited in the log to kmemcheck). But
> >  > because it touches SLUB (because it has to - and they are acked by
> >  > Pekka) i never had the chance to move it into the for-akpm branch.
> >
> >  Does it really really really need to consume one of our few remaining page
> >  flags?  We'll be in a mess when we run out.
> 
> Actually it doesn't. I attach a patch which gets rid of the page flag,
> and we rely instead on the PTE flag for page-trackedness.
> 
> The reason we didn't do this at once is that the making of kmemcheck
> has been pretty much my first introduction to SLUB, x86, page flags,
> etc., and the actual semantics of the various introduced flags have
> varied since the first version of kmemcheck. At this point, the struct
> page flags weren't actually needed anymore, but they were convenient.
> 
> My apologies for not inlining the patch -- I don't have a mail client
> that won't mess up whitespace. It can also be downloaded at:
> http://folk.uio.no/vegardno/linux/0001-kmemcheck-remove-use-of-tracked-page-flag.patch
> 
> The patch has received minimal amount of testing, but I've
> double-checked the logic. It boots fine on my laptop, boot log at:
> http://folk.uio.no/vegardno/linux/kmemcheck-20080417.txt
> 
> Ingo, will you take this for some additional testing?
> 

If you're OK with doing it this way then it would be preferable.

> diff --git a/arch/x86/kernel/kmemcheck.c b/arch/x86/kernel/kmemcheck.c
> index 16dce10..d82f35d 100644
> --- a/arch/x86/kernel/kmemcheck.c
> +++ b/arch/x86/kernel/kmemcheck.c
> @@ -233,12 +233,27 @@ param_kmemcheck(char *str)
>  	if (!str)
>  		return -EINVAL;
>  
> -	sscanf("%d", str, &kmemcheck_enabled);
> +	sscanf(str, "%d", &kmemcheck_enabled);
>  	return 0;
>  }

whoops.  Note to Ingo: unrelated bugfix in there.

>  early_param("kmemcheck", param_kmemcheck);

kmemcheck= is documented in at least three places, which is nice, but it
isn't mentioned in the place where we document kernel-parameters:
Documentation/kernel-parameters.txt.  A brief section there which directs
the user to the extended docs would be fine.

early_param() is unusual - we normally use __setup().  I assume there's a
reason for using early_param(), but that reason cannot be discerned from
reading the code.  A /*comment*/ is the way to fix that.

> +static pte_t *
> +address_get_pte(unsigned int address)

This is not the preferred way of laying out function declarations but I've
basically given up on this one.

> +{
> +	pte_t *pte;
> +	int level;
> +
> +	pte = lookup_address(address, &level);
> +	if (!pte)
> +		return NULL;
> +	if (!pte_hidden(*pte))
> +		return NULL;
> +
> +	return pte;
> +}
> +
>  /*
>   * Return the shadow address for the given address. Returns NULL if the
>   * address is not tracked.
> @@ -249,88 +264,53 @@ early_param("kmemcheck", param_kmemcheck);
>  static void *
>  address_get_shadow(unsigned long address)
>  {
> +	pte_t *pte;
>  	struct page *page;
>  	struct page *head;
>  
>  	if (!virt_addr_valid(address))
>  		return NULL;
>  
> +	pte = address_get_pte(address);
> +	if (!pte)
> +		return NULL;
> +
>  	/* The accessed page */
>  	page = virt_to_page(address);
> -	if (!PageCompound(page))
> -		return NULL;
> +	BUG_ON(!PageCompound(page));
>  
>  	/* The head page */
>  	head = compound_head(page);
> -	if (!PageTracked(head))
> -		return NULL;
> +	BUG_ON(compound_order(head) == 0);
>  
>  	return (void *) address + (PAGE_SIZE << (compound_order(head) - 1));
>  }

	(void *)address

is more common, but I'm close to giving up on that too.

>  static int
> -show_addr(uint32_t addr)
> +show_addr(uint32_t address)

u32 is preferred, but ditto.

>  {
>  	pte_t *pte;
> -	int level;
> -
> -	if (!address_get_shadow(addr))
> -		return 0;
> -
> -	pte = lookup_address(addr, &level);
> -	BUG_ON(!pte);
> -
> -	if (level != PG_LEVEL_4K)
> -		return 0;
> -
> -	set_pte(pte, __pte(pte_val(*pte) | _PAGE_PRESENT));
> -	__flush_tlb_one(addr);
> -	return 1;
> -}
>
> ...
>
> --- a/include/linux/kmemcheck.h
> +++ b/include/linux/kmemcheck.h
> @@ -9,6 +9,8 @@ void kmemcheck_init(void);
>  void kmemcheck_show_pages(struct page *p, unsigned int n);
>  void kmemcheck_hide_pages(struct page *p, unsigned int n);
>  
> +bool kmemcheck_page_is_tracked(struct page *p);
> +
>  void kmemcheck_mark_unallocated(void *address, unsigned int n);
>  void kmemcheck_mark_uninitialized(void *address, unsigned int n);
>  void kmemcheck_mark_initialized(void *address, unsigned int n);
> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> index 63f5fd8..3696889 100644
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -89,7 +89,6 @@
>  #define PG_mappedtodisk		16	/* Has blocks allocated on-disk */
>  #define PG_reclaim		17	/* To be reclaimed asap */
>  #define PG_buddy		19	/* Page is free, on buddy lists */
> -#define PG_tracked		20	/* Tracked by kmemcheck */
>  
>  /* PG_readahead is only used for file reads; PG_reclaim is only for writes */
>  #define PG_readahead		PG_reclaim /* Reminder to do async read-ahead */
> @@ -297,10 +296,6 @@ static inline void __ClearPageTail(struct page *page)
>  #define SetPageUncached(page)	set_bit(PG_uncached, &(page)->flags)
>  #define ClearPageUncached(page)	clear_bit(PG_uncached, &(page)->flags)
>  
> -#define PageTracked(page)	test_bit(PG_tracked, &(page)->flags)
> -#define SetPageTracked(page)	set_bit(PG_tracked, &(page)->flags)
> -#define ClearPageTracked(page)	clear_bit(PG_tracked, &(page)->flags)
> -

That's about 15 less rejects I have to fix ;)
 
>  struct page;	/* forward declaration */
>  
> diff --git a/mm/slub.c b/mm/slub.c
> index 9b58979..7a544e6 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -1125,7 +1125,7 @@ static void __free_slab(struct kmem_cache *s, struct page *page)
>  		ClearSlabDebug(page);
>  	}
>  
> -	if (PageTracked(page) && !(s->flags & SLAB_NOTRACK)) {
> +	if (kmemcheck_page_is_tracked(page) && !(s->flags & SLAB_NOTRACK)) {
>  		kmemcheck_free_slab(s, page, pages);
>  		return;
>  	}

Perhaps we should get all this code onto the list(s) for re-review.  It's
been a while..


^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17 18:51                 ` Ingo Molnar
@ 2008-04-17 19:57                   ` Andrew Morton
  2008-04-17 20:18                     ` Ingo Molnar
  2008-04-18  9:33                   ` Tomasz Kłoczko
  1 sibling, 1 reply; 71+ messages in thread
From: Andrew Morton @ 2008-04-17 19:57 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: hch, penberg, linux-kernel, torvalds, arjan, John Levon, Philippe Elie

On Thu, 17 Apr 2008 20:51:58 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > afaik the sysprof-vs-oprofile issue still hasn't been settled.  Maybe 
> > it's no longer a relevant question with the new code - I just don't 
> > know. Everything went all quiet and then this stuff happened.
> 
> i dont think there's any big issue here. Sysprof is a time and stack 
> system-wide tracer/profiler, oprofile profiles CPU events - deep 
> stacktracing is an afterthought there. And how do you set up oprofile to 
> do precise time events?
> 
> with sysprof you can do:
> 
>   cd /sys/kernel/debug/tracing
>   echo sysprof > current_tracer
>   cat trace_pipe
> 
> and you'll see the trace events go by, live. The user-space bits of 
> sysprof have been ported over to ftrace/sysprof already and it's a 
> really nice tool that shows a deep stack-trace based hierarchical 
> "vertical" profile instead of the usual finegrained profile.

Well that's all good to hear but I don't know where you're getting your
information from.  In the past month and a half I've seen zero email from
Soeren and a single ftrace-related patch.

So right now I do not have enough information to understand what ftrace
does, let alone to compare it with oprofile.

And this is a problem.  I, probably more than anyone else, work with bug
reporters on kernel problems and I am not in a position to be able to
direct them to use an important new tool.  There isn't even a documentation
file I can point them at.

I'd imagine that a large number of the current kernel development team only
vaguely know of ftrace's existence, let alone how to use it and what its
advantages are.  So they just won't use it.

> It certainly helps that the author of the tracer plugin (Soeren 
> Sandmann) is the author of the userspace app too - so there's a rather 
> well-working feedback loop here ;-)
> 
> With oprofile all these things are rather indirect, the API is more 
> complex, it forces per-CPU buffers, etc. etc. I think for 
> instrumentation the driving force must be usability, and sysprof/ftrace 
> is hands down more usable - to me at least.

Well.  You know how to use it.

John, Phillippe: have you had a chance to take a look at the latest ftrace
code?

Thanks.

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17 19:57                   ` Andrew Morton
@ 2008-04-17 20:18                     ` Ingo Molnar
  0 siblings, 0 replies; 71+ messages in thread
From: Ingo Molnar @ 2008-04-17 20:18 UTC (permalink / raw)
  To: Andrew Morton
  Cc: hch, penberg, linux-kernel, torvalds, arjan, John Levon, Philippe Elie


* Andrew Morton <akpm@linux-foundation.org> wrote:

> Well that's all good to hear but I don't know where you're getting 
> your information from.  In the past month and a half I've seen zero 
> email from Soeren and a single ftrace-related patch.

... well, this all originates from the latency tracer in -rt. Which goes 
back years, it's frequently utilized and it helped us fix many bugs. 
Ftrace has been frequently posted to lkml and is being developed in 
sched-devel.git - and we dont repost the series on lkml because it's 
lots of patches now (and the concept didnt change much anyway, we just 
got more plugins). The URL to monitor sched-devel.git changes is:

    http://people.redhat.com/mingo/sched-devel.git/README

(see the shortlog below) [ Note: the commit logs are not tidied up and 
backmerged yet - and the x86 commits are there too - this will get 
cleaner once the first, largest phase of x86.git goes upstream. ]

Regaring utility, off the top of my head here are a few recent 
fixes/improvements we did with the help of ftrace's scheduler tracer 
component or with other ftrace components:

|  commit f540a6080a092e2ab69fd146c308022db7347b0a
|  Author: Ingo Molnar <mingo@elte.hu>
|  Date:   Sat Mar 15 17:10:34 2008 +0100
|
|      sched: wakeup-buddy tasks are cache-hot

|  commit 4ae7d5cefd4aa3560e359a3b0f03e12adc8b5c86
|  Author: Ingo Molnar <mingo@elte.hu>
|  Date:   Wed Mar 19 01:42:00 2008 +0100
|
|      sched: improve affine wakeups

|  commit aa2ac25229cd4d0280f6174c42712744ad61b140
|  Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
|  Date:   Fri Mar 14 21:12:12 2008 +0100
|
|     sched: fix overload performance: buddy wakeups

|  commit bead9a3abd15710b0bdfd418daef606722d86282
|  Author: Ingo Molnar <mingo@elte.hu>
|  Date:   Wed Apr 16 01:40:00 2008 +0200
|
|     mm: sparsemem memory_present() fix

and that's just me. So i'm not worried at all whether it will be used.

	Ingo

------------------->
Adrian Bunk (1):
      x86: remove the write-only timer_uses_ioapic_pin_0

Akinobu Mita (6):
      x86: avoid redundant loop in io_apic_level_ack_pending()
      x86: use ioapic_read_entry() and ioapic_write_entry()
      x86: remove unnecessary memset()
      x86: remove unnecessary tmp local variable
      x86: use cpumask_of_cpu()
      x86: use cpu_online()

Alan Mayer (1):
      x86: resize NR_IRQS for large machines

Alexander van Heukelum (25):
      x86: reserve end-of-conventional-memory to 1MB on 32-bit
      x86: reserve_early end-of-conventional-memory to 1MB, 64-bit
      x86: reserve end-of-conventional-memory to 1MB, 64-bit
      x86: reserve end-of-conventional-memory to 1MB, 32-bit, use paravirt_enabled
      x86: reserve end-of-conventional-memory to 1MB, 64-bit, use paravirt_enabled
      x86: remove superfluous initialisation in boot code.
      x86: cleanup boot-heap usage
      x86: change x86 to use generic find_next_bit
      x86: fix uml with generic find_next_bit for x86
      x86, generic: optimize find_next_(zero_)bit for small constant-size bitmaps
      x86: merge the simple bitops and move them to bitops.h
      x86: K8, GEODE_LX, CRUSOE, EFFICEON and CORE2 support the cmovxx instructions.
      generic: introduce a generic __fls implementation
      generic: implement __fls on all 64-bit archs
      Use __fls for fls64 on 64-bit archs
      x86: generic versions of find_first_(zero_)bit, convert i386
      x86: switch x86_64 to generic find_first_bit
      x86: optimize find_first_bit for small bitmaps
      x86: remove x86-specific implementations of find_first_bit
      x86: finalize bitops unification
      Build fix for uml/i386
      Build fix for uml/x86_64
      uml: cleanup: use def_bool in Kconfig files
      powerpc: fix find_next_bit breakage on ppc and powerpc
      x86: fix warning in "x86: clean up vSMP detection"

Alexey Dobriyan (1):
      arch/x86/: switch to proc_create()

Alexey Starikovskiy (72):
      x86: move quad_local_to_mp_bus_id to numa.c
      x86: add mp_bus_not_pci bitmap to mpparse_32.c
      x86: use not_pci bitmap #1
      x86: use not_pci bitmap #2
      x86: use not_pci bitmap #3
      x86: use not_pci bitmap #4
      x86: use not_pci bitmap #5
      x86: use not_pci bitmap #6
      x86: rearrange bus_type parse
      x86: make mp_bus_id_to_type optional
      x86: move mp_bus_id_to_local to numa.c
      Move mp_bus_id_to_node to numa.c
      x86: lindent mpparse_64.c
      x86: add bad_ioapic to mpparse_32.c
      x86: add uniq_ioapic_id to mpparse_32.c
      x86: use get_bios_ebda in mpparse_64.c
      x86: limit scan to 1k of EBDA.
      x86: rename gsi_start to gsi_base to match mpparse_32.c
      x86: remove mpc_apic_id()
      x86: remove mpc_oem_pci_bus()
      x86: remove mpc_oem_bus_info()
      x86: make struct mpc_config_translation NUMAQ-only
      x86: use same index for processor maps
      x86: move es7000_plat closer to its user
      x86: don't call MP_processor_info for disabled cpu
      x86: separate generic_processor_info into its own function
      x86: don't use MP_processor_info for ACPI mode
      x86: move apic_ver array to apic_32.c
      x86: move mp_lapic_addr to apic_32.c
      x86: move phys_cpu_present_map to smpboot.c
      x86: move num_processors to smpboot.c
      x86: move disabled_cpus to smpboot.c
      x86: move def_to_bigsmp to setup_32.c
      x86: move boot_cpu_physical_apicid to apic_32.c
      x86: move x86_bios_cpu_apicid to apic_32.c
      x86: move generic_processor_info to apic_32.c
      x86: don't call MP_processor_info for disabled cpu (64bit)
      x86: separate generic_processor_info into its own function (64bit)
      x86: don't use MP_processor_info for ACPI mode (64bit)
      x86: move mp_lapic_addr to apic_64.c
      x86: move phys_cpu_present_map to smpboot.c (64bit)
      x86: move num_processors to smpboot.c (64 bit)
      x86: move disabled_cpus to smpboot.c (64bit)
      x86: move boot_cpu_physical_apicid to apic_64.c
      x86: move generic_processor_info to apic_64.c
      x86: move x86_bios_cpu_apicid to io_apic_64.c
      x86: move x86_cpu_to_apicid to setup.c
      x86: move phys_cpu_present_map to setup.c
      x86: move x86_cpu_to_apicid_init to smpboot.c
      x86: move x86_bios_cpu_apicid_init to smpboot.c
      x86: Don't set IO APIC features if IO APIC is not enabled
      x86: move mp_ioapics to io_apic_32.c
      x86: move mp_ioapics to io_apic_64.c
      x86: move mp_ioapic_routing to boot.c
      x86: move mp_irqs to io_apics_32.c
      x86: move mp_irqs to io_apic_64.c
      x86: move up & smp variables to setup.c
      x86: move mp_register_lapic to boot.c
      x86: move mp_register_lapic_address to boot.c
      x86: Lindend mpparse_32.c
      x86: add early flags to mpparse_32.c
      x86: unify arch/x86/kernel/mpparse_64.c
      x86: unify mp_bus_info
      x86: unify smp_read_mpc
      x86: unify construct_default_ioirq_mptable
      x86: unify get_smp_config
      x86: unify smp_scan_config
      x86: unify uniq_io_apic_id
      x86: unify mp_register_ioapic
      x86: unify mp_config_acpi_legacy_irqs
      x86: unify mp_register_gsi
      x86: merge mpparse_{32,64}.c

Alok Kataria (1):
      x86: fix paranoia about using BIOS quickboot mechanism.

Andi Kleen (13):
      x86: do kernel direct mapping at boot using GB pages
      x86: use year 2000 offset for cmos clock
      x86: add warning when RTC clock reports binary
      x86: enable ACPI extended century handling for 32bit
      x86: don't set up early exception handlers for external interrupts
      x86: replace early exception setup macro recursion with loop
      x86: move early exception handlers into init.text
      x86: implement true end_pfn_mapped for 32bit
      x86: account overlapped mappings in max_pfn_mapped
      x86: add set_memory_4k to pageattr.c
      x86: don't use large pages to map the first 2/4MB of memory
      x86: re-add rdmsrl_safe
      x86: split large page mapping for AMD TSEG

Andres Salomon (1):
      x86: geode: MSR cleanup

Andrew Morton (3):
      i386: arch/x86/math-emu/fpu_entry.c warning fix
      i386: arch/x86/math-emu/reg_ld_str.c: fix warning
      x86, ptrace: PEBS support, warning fix

Ankita Garg (1):
      Fix conversion of task state to char in latency tracer

Arjan van de Ven (6):
      x86: add code to dump the (kernel) page tables for visual inspection by kernel developers
      x86: setup stack canary for the idle threads
      x86: introduce /dev/mem restrictions with a config option
      x86: add CONFIG_CC_STACKPROTECTOR selftest
      x86: mark init_mm deprecated
      x86: add comments to describe the new api's in cacheflush.h

Arnaldo Carvalho de Melo (3):
      x86: reducing debuginfo size by removing unneeded includes
      ftrace: annotate core code that should not be traced
      ftrace: add basic support for gcc profiler instrumentation

Auke Kok (1):
      e1000e: set CONFIG_E1000E=y in x86 defconfigs

Ben Castricum (1):
      x86: microcode: show results on success too

Björn Steinbrink (1):
      x86, pci: fix off-by-one errors in some pirq warnings

Christian Limpach (1):
      xen blkfront: Delay wait for block devices until after the disk is added

Cyrill Gorcunov (4):
      x86: processor.h - use PAGE_SIZE instead of numeric value
      x86: relocate_kernel - use predefined PAGE_SIZE instead of own alias
      x86: entry_32.S - use flags from processor-flags.h
      x86: debug Store - call kfree if only we really need it

Daniel Walker (1):
      sched: fix whitespace additions

Dave Jones (1):
      x86: Centaur Isaiah processor to use sysenter in 64-bit compatibility mode rather than syscall

David P. Reed (3):
      x86: fix cmos read and write to not use inb_p and outb_p
      x86: define outb_pic and inb_pic to stop using outb_p and inb_p
      x86: use explicit timing delay for pit accesses in kernel and pcspkr driver

Dhaval Giani (2):
      sched: cleanup cpuacct variable names
      sched: allow cpuacct stats to be reset

Dmitry Adamushko (1):
      latencytop: optimize LT_BACKTRACEDEPTH loops a bit

Eric Dumazet (1):
      percpu: introduce DEFINE_PER_CPU_PAGE_ALIGNED() macro

Eric W. Biederman (1):
      x86: introduce kernel/head32.c

Erik Bosman (3):
      generic, x86: add prctl commands PR_GET_TSC and PR_SET_TSC
      x86: implement prctl PR_GET_TSC and PR_SET_TSC
      generic, x86: add tests for prctl PR_GET_TSC and PR_SET_TSC

Florian Fainelli (1):
      x86, rdc321x: remove watchdog file

Gautham R Shenoy (1):
      x86: Don't send RESCHEDULE_VECTOR to offlined cpus

Glauber Costa (110):
      x86: change vsmp compile dependency
      x86: make vsmp_init void, instead of static int
      x86: call vsmp_init explicitly
      introduce paravirt helpers
      use the paravirt helpers
      x86: commonize smp.h
      x86: merge extern function definitions
      x86: merge extern variables definitions
      x86: define smp_ops in common header
      x86: move smp_ops extern declaration to common header
      x86: merge smp_send_reschedule
      x86: unify smp_call_function_mask
      x86: unify __cpu_up.
      x86: unify prepare_boot_cpu
      x86: unify smp_prepare_cpus
      x86: unify smp_cpus_done
      x86: move disabled_cpus to common header
      x86: use disabled_cpus in i386
      x86: move prefill_possible_map to common file
      x86: remove export for smp_call_function_mask.
      x86: remove irqs disabled warning.
      x86: create smpcommon.c
      x86: provide __smp_call_function
      x86: change x86_64 smp_call_function_mask to look alike i386
      x86: provide hlt_works function.
      x86: make stop_this_cpu looks exactly equal in both arches
      x86: add reboot_force test to native_smp_send_stop
      x86: unify smp_send_stop
      x86: create smp.c
      x86: create ipi.c
      x86: create tlb files
      x86: get rid of smp_32.c and smp_64.c
      x86: remove cpu_llc_id from processor.h
      x86: adjust types in smpcommon_32.c
      x86: move equal types to common file
      x86: make set_cpu_sibling_map nonstatic
      x86: make remove_siblinginfo non-static
      x86: move hotplug related extern definitions to smp.h
      x86: move sibling functions to common file
      x86: move cpu_coregroup_map to common file
      x86: remove vector_lock around cpu_online_map
      x86: use remove_from_maps in cpu_disable
      x86: do not clear cpu_online_map
      x86: merge __cpu_disable and cpu_die
      x86: make x86_64 accept the max_cpus parameter
      x86: move trampoline arrays extern definition to smp.h
      x86: adapt voyager's trampoline_base
      x86: adapt voyager's setup_trampoline
      x86: unify setup_trampoline
      x86: use wait_for_init_deassert in x86_64
      x86: use cpu_relax instead of rep_nop
      x86: move ipi definitions to mach_ipi.h
      move apic declarations to mach_apic.h
      x86: surround hard_smp_processor_id in APIC_DEFINITION
      x86: provide bogus hard_smp_processor_id
      x86: merge hard/logical_smp_processor_id
      x86: surround apic headers in apic definitions
      x86: merge includes in smp.h
      x86: split safe_smp_processor_id
      x86: merge SMP definitions of smp.h
      x86: change naming of cpu_initialized_mask for xen
      x86: merge smp_32.h and smp_64.h into smp.h
      x86: move dma_ops struct definition to dma-mapping.h
      x86: implement dma_map_single through dma_ops
      x86: move dma_unmap_single to common header
      x86: move dma_map_sg to common header
      x86: move dma_unmap_sg to common header
      x86: move dma_sync_single_for_cpu to common header
      x86: move dma_sync_single_for_device to common header
      x86: move dma_sync_single_range_for_cpu to common header
      x86: move dma_sync_single_range_for_device to common header
      x86: move dma_sync_sg_for_cpu to common header
      x86: move dma_sync_sg_for_device to common header
      x86: move alloc and free coherent to common header
      x86: move dma_map_page and dma_unmap_page to common header
      x86: move dma_cache_sync to common header
      x86: move dma_supported and dma_set_mask to pci-dma_32.c
      x86: align to clflush size
      x86: provide a bad_dma_address symbol for i386
      x86: unify dma_mapping_error
      x86: move ARCH_HAS_DMA_DECLARE_COHERENT_MEMORY to dma-mapping.h
      x86: delete the arch-specific dma-mapping headers.
      x86: introduce pci-dma.c
      x86: delete empty functions from pci-nommu_64.c
      x86: implement mapping_error in pci-nommu_64.c
      x86: Add flush_write_buffers in nommu functions
      x86: use sg_phys in x86_64
      x86: use WARN_ON in mapping functions
      x86: use dma_length in i386
      x86: move definition to pci-dma.c
      x86: unify pci-nommu
      x86: move initialization functions to pci-dma.c
      x86: move x86_64-specific to common code.
      x86: move pci fixup to pci-dma.c
      x86: merge dma_supported
      x86: merge iommu initialization parameters
      x86: move dma_coherent functions to pci-dma.c
      x86: isolate coherent mapping functions
      x86: move bad_dma_address
      x86: adjust dma_free_coherent for i386
      x86: remove virt_to_bus in pci-dma_64.c
      x86: use numa allocation function in i386
      x86: use a fallback dev for i386
      x86: don't try to allocate from DMA zone at first
      x86: retry allocation if failed
      x86: unify gfp masks
      x86: remove kludge from x86_64
      x86: return conditional to mmu
      x86: don't do dma if mask is NULL.
      x86: integrate pci-dma.c

Glauber de Oliveira Costa (78):
      x86: change var types in __inquire_remote_apic
      x86: add loglevel to printks
      x86: use apic_*_around instead of apic_write in x86_64
      x86: use start_ipi_hook in x86_64
      x86: add an smp_apply_quirks to smpboot_32.c
      x86: decouple call to print_cpu_info from smp_store_cpu_info
      x86: provide specialized identification routines for x86_64
      x86: use identify_boot_cpu
      x86: call identify_secondary_cpu in smp_store_cpu_info
      x86: merge smp_store_cpu_info
      x86: always enable irqs when entering idle
      x86: don't call local_irq_enable before entering idle
      x86: move setup_secondary_clock a little bit down in the function
      x86: move state update out of ipi_lock
      x86: provide APIC_INTEGRATED definition for x86_64
      x86: use APIC_INTEGRATED tests in x86_64
      x86: add barriers statement
      x86: isolate sanity checking
      x86: isolate logic to disable smp
      x86: do tests before do_boot_cpu in i386
      x86: make __smp_prepare_cpu void
      x86: move assignment of CPU_PREPARE before do_boot_cpu
      x86: unify extern masks declaration
      x86: define bios to apicid mapping
      x86: initialize map pointers in setup_32.c
      x86: make node to apic mapping declarations unconditional
      x86: fix alloc_bootmem_pages_node macro
      x86: use specialized routine for setup per-cpu area
      x86: fill bios cpu to apicid maps
      x86: fill cpu to apicid and present map in mpparse
      x86: get rid of cpucount
      x86: allow user to impress friends.
      x86: do smp tainting checks in a separate function
      x86: move impress_friends and smp_check to cpus_done
      x86: add subarch support (for headers) to x86_64
      x86: include mach_wakecpu.h in smpboot_64
      x86: include smpboot_hooks.h in smpboot_64.c
      x86: move smp_intr_init away from smpboot_32.c
      x86: don't set maps in native_smp_prepare_boot_cpu()
      x86: wipe get_nmi_reason out of nmi_64.h
      x86: unify nmi_32.h and nmi_64.h
      x86: call check_nmi_watchdog explicitly in native_smp_cpus_done
      x86: call nmi_watchdog_default in i386
      x86: don't initialize sibling and core maps during preparation
      x86: schedule work only if keventd is already running
      x86: do not zap_low_mappings in __smp_prepare_cpus
      x86: boot cpus from cpu_up, instead of prepare_cpus
      x86: get rid of commenced mask.
      x86: use create_idle struct in do_boot_cpu
      x86: don't span a new worker in __smp_prepare_cpu
      x86: modify smp_callin in x86_64 to look like i386
      x86: wrap esr setting up in i386 in lapic_setup_esr
      x86: provide an end_local_APIC_setup function
      x86: calibrate delay with irqs enabled
      x86: minor adjustments for do_boot_cpu
      x86: call do_boot_cpu directly from native_cpu_up
      x86: include mach_apic.h in smpboot_64.c and smpboot.c
      x86: change wakeup_secondary name
      x86: add callin tests to cpu_up
      x86: move {un}map_cpu_to_logical_apicid to smpboot.c
      x86: move stack_start to smp.h
      x86: change boot_cpu_id to boot_cpu_physical_apicid
      x86: integrate do_boot_cpu
      x86: integrate start_secondary
      x86: merge smp_prepare_boot_cpu
      x86: merge native_smp_cpus_done
      x86: use physical id when disabling smp
      x86: get rid of smp_boot_cpus
      x86: additions to i386 native_smp_prepare_cpus.
      x86: assign nr_ioapics = 0 in smpboot_hooks.h
      x86: change x86_64 native_smp_prepare_cpus to match i386
      x86: add extra sanity check
      x86: change x86_64 sanity checks to match i386.
      x86: introduce smpboot_clear_io_apic
      x86: merge native_smp_prepare_cpus
      x86: merge cpu_exit_clear
      x86: move apicid mappings to smpboot.c
      x86: remove smpboot_32.c and smpboot_64.c

Gregory Haskins (1):
      sched: fix cpus_allowed settings

Guillaume Chazarain (1):
      sched: fix rq->clock overflows detection with CONFIG_NO_HZ

H. Peter Anvin (2):
      x86: unify arch/x86/mm/Makefile
      x86: clean up the page table dumper and add 32-bit support

Harvey Harrison (11):
      x86: change most X86_32 pt_regs members to unsigned long
      x86: make X86_32 pt_regs members unsigned long
      x86: regparm(3) is mandatory, no need to annotate
      x86: reduce trivial style differences in signal_32|64.c
      x86: Use FIX_EFLAGS define in X86_64
      x86: use sizeof(long) to unify signal_32|64.c
      x86: move struct definitions to unifed sigframe.h
      x86: Unify argument names in signal_32|64.c
      x86: define DEBUG_SIG in signal_64.c
      x86: replace remaining __FUNCTION__ occurances
      x86: pageattr.c fix shadowed variable warning

Hidetoshi Seto (2):
      sched, cpuset: customize sched domains, docs
      sched, cpuset: customize sched domains, core

Hiroshi Shimamoto (6):
      x86: split cpuinfo from setup_64.c into cpu/proc_64.c
      x86: make cpu/proc|_64.c similar
      x86: add power management line in /proc/cpuinfo
      x86: cosmetic unification cpu/proc|_64.c
      x86: unify cpu/proc|_64.c
      x86: X86_HT always enable on X86_64 SMP

Huang, Ying (5):
      x86: EFI_PAGE_SHIFT fix
      x86, boot: add free_early to early reservation machanism
      x86, boot: add linked list of struct setup_data
      x86, boot: export linked list of struct setup_data via debugfs
      x86, boot: Document for linked list of struct setup_data

Hugh Dickins (1):
      x86: MPSC should use P6 NOPs

Ian Campbell (4):
      x86: use ELF format in compressed images.
      x86: add a crc32 checksum to the kernel image.
      x86: reduce arch/x86/mm/ioremap.o size
      x86: boot protocol updates

Ingo Molnar (155):
      x86: check vmlinux limits, 64-bit
      x86: increase the kernel text limit to 512 MB
      x86: fix the pagetable dumper
      x86: add gbpages switches
      x86: bump image header to version 2.08.
      x86: clean up mmx_32.c
      x86: more coding style fixes in centaur.c
      x86: clean up include/asm-x86/processor.h
      x86: more cleanups in arch/x86/boot/compressed/misc.c
      x86: de-macro start_thread()
      x86: clean up cpu capabilities accesses
      x86: clean up cpu capabilities accesses, generic
      x86: clean up cpu capabilities accesses, amd.c
      x86: clean up cpu capabilities accesses, centaur.c
      x86: clean up cpu capabilities accesses, common.c
      x86: clean up cpu capabilities accesses, cyrix.c
      x86: clean-up-cpu-capabilities-intel.c.patch
      x86: clean up cpu capabilities accesses, transmeta.c
      x86: clean up traps_32.c
      x86, tracing: add notrace to asm-x86/linkage.h
      x86: ioremap(), extend check to all RAM pages
      x86: patches/lguest-fix4.patch
      x86: warn about RAM pages in ioremap()
      x86: redo cded932b75ab0a5f9181e
      x86: debug pmd_bad()
      x86: stackprotector & PARAVIRT fix
      x86: fix stackprotector canary updates during context switches
      x86: fix canary of the boot CPU's idle task
      panic: print more informative messages on stackprotect failure
      panic: print out stacktrace if DEBUG_BUGVERBOSE
      x86: enable stack-protector by default
      stackprotector: include files
      stackprotector: add boot_init_stack_canary()
      x86: fix the stackprotector canary of the boot CPU
      x86: stackprotector: mix TSC to the boot canary
      x86: unify stackprotector features
      x86: clean up switch_to()
      x86: fix switch_to() clobbers
      x86: add comments to processor.h
      x86: clean up i387.c
      x86: remove DEBUG_SIG
      x86: clean up arch/x86/kernel/signal_32.c
      x86: move extern declaration to vdso.h
      x86: add KERN_INFO to show_unhandled_signals printout
      x86: remove mach_reboot.h
      x86: fill cpu to apicid and present map in mpparse, fix
      x86: vsmp fix x86 vsmp fix is vsmp box cleanup
      debugging: always enable stacktrace
      x86: revert ucminus change
      x86: fix ioapic bug again
      x86: PAT fix
      undo "x86: fix breakage of vSMP irq operations"
      x86: tom2 warning fix
      x86: spinlock ops are always-inlined
      x86: ioremap of 64-bit resource on 32-bit kernel fix
      unify: mpparse2 move disabled cpus to smpboot c fix
      unify: mpparse2 move boot cpu physical apicid to apic 32 c fix
      unify: mpparse2 move generic processor info to apic 32 c fix
      unify: move phys cpu present map to smpboot.c, 64bit, prepare
      x86: mpparse: 64-bit fix
      x86: cleanup replace most vm86 flags with flags from processor-flags.h, fix
      x86: support for new UV apic, prepare
      x86: uv fix
      x86: set_cyc2ns_scale() remove prev scale
      x86: improve default idle
      pat: cleanup
      x86: extend the scheduled bzImage symlinks removal
      x86: 4kstacks default
      unify: mpparse4 x86 don t set io apic features if io apic is not enabled fix
      x86: add optimized inlining
      generic: optimized inlining, fix
      x86: clean up cpu capabilities accesses, p4-clockmod.c
      nohz: fix typo in tick-broadcast.c
      kgdb: light v16
      kgdb: IPI fixup
      x86: fix k8-bus_64.c build
      x86: sanity check gart for buggy device, fix
      x86: xen unify x86 add common mm pgtable c fix
      x86: dma-ops on highmem fix
      kmemcheck: fix-up (some bogus) reports
      x86: kmemcheck v7 fix
      kmemcheck: config
      x86: add x86-latest.git tag
      x86: standalone trampoline code
      x86: rename find_max_pfn() to propagate_e820_map()
      sched: re-do "sched: fix fair sleepers"
      sched: make cpu_clock() globally synchronous
      x86: patches/sched-feat-sync-wakeups.patch
      sched: feat affine wakeups
      sched: cache hot buddy
      sched: reenable sync wakeups
      sched: remove sysctl_sched_batch_wakeup_granularity
      sched: add latency tracer callbacks to the scheduler
      tracing: add notrace to linkage.h
      ftrace: fix kexec
      ftrace: cleanups, #1
      ftrace: add readme
      ftrace: fix #2
      ftrace: fix
      ftrace: cleanups
      ftrace: timestamp syncing, prepare
      ftrace: fast, scalable, synchronized timestamps
      ftrace: remove-idx-sync
      ftrace: clean-up-pipe-iteration
      ftrace: add raw output
      ftrace: bin-output
      ftrace: add sysprof plugin
      time: add ns_to_ktime()
      ftrace: extend-sysprof-plugin
      ftrace: add-special-trace
      ftrace: extend-sysprof-plugin2
      ftrace: sysprof-plugin, #3
      ftrace: sysprof plugin improvement
      ftrace, fix #5
      ftrace: fix #6
      ftrace: sysprof fix
      ftrace: use cpu clock again
      ftrace: cpu_clock & ftrace fix
      ftrace: fix #8
      ftrace: introduce the "hex" output method
      x86: ../../patches/ftrace-fix10.patch
      ftrace: fix #11
      ftrace: fix #12
      ftrace: fix #13
      ftrace: disable -pg for the tracer itself
      x86: ../../patches/ftrace-remove-notrace.patch
      x86: ../../patches/ftrace-add-wakeup-events-to-sched-tracer.patch
      ftrace: add stack tracing
      ftrace: sched tracer fix
      ftrace: make nostacktrace the default
      ftrace: sched tracer, trace full rbtree
      ftrace: trace curr/next tasks
      ftrace: fix wakeups
      ftrace: fix __trace_special()
      x86: patches/ftrace-sched-tree-trace-switch.patch
      x86: ../../patches/ftrace-cpu-mask.patch
      x86: patches/ftrace-cpu-mask-use.patch
      ftrace: fix cmdline tracing
      ../../patches/ftrace: iter ctrl fix
      ftrace: include cpu in stacktrace
      ftrace: sched tree fix
      ftrace: sched special
      sched: fix checks
      ftrace: debug reduce
      sysprof: update copyrights
      no: ad hoc ftrace
      softlockup: hung tasks check
      seqlock: livelock fix
      ftrace: restrict tracing to HAVE_FTRACE architectures
      Merge branch 'latest' of /home/mingo/linux-2.6-x86 into latest
      sched: system sets genirq system set irq affinities, fix
      mmiotrace: ftrace fix
      mmiotrace: cleanup
      softlockup: allow panic on lockup
      sched: add sched-devel.git tag

Isaku Yamahata (12):
      xen: definisions which ia64 needs
      xen: definitions which ia64/xen needs
      xen: add missing definitions for xen grant table which ia64/xen needs
      xen: add missing definitions in include/xen/interface/vcpu.h which ia64/xen needs
      xen: move features.c from arch/x86/xen/features.c to drivers/xen
      xen: move events.c to drivers/xen for IA64/Xen support
      Xen: make events.c portable for ia64/xen support
      xen: add resend_irq_on_evtchn() definition into events.c
      xen: make include/xen/page.h portable moving those definitions under asm dir
      xen: replace callers of alloc_vm_area()/free_vm_area() with xen_ prefixed one
      xen: make grant table arch portable
      xen: import arch generic part of xencomm

Jacek Luczak (10):
      x86: remove vm86.h inclusion from process_32.c
      x86: e820_64, fix section mismatch warning
      x86: section mismatch fixes, #1
      x86: setup_trampoline() - fix section mismatch warning
      x86: section mismatch fixes, #2
      x86: section mismatch fixes, #3
      x86: trampoline_32.S - switch to .cpuinit.data
      x86: uniq_ioapic_id - fix section mismatch warning
      x86: unlock_ExtINT_logic() - fix section mismatch warnings
      x86: pgtable_32.h - prototype and section mismatch fixes

Jack Steiner (12):
      x86: increase max physical memory size of 64-bit
      x86: allow NODES_SHIFT to be a config option on x86_64
      x86: change GET_APIC_ID() from an inline function to an out-of-line function
      x86: add functions to determine if platform is a UV platform
      x86: increase size of APICID
      x86: parsing for ACPI "SAPIC" table
      x86: add UV specific header for MMR definitions
      x86: define the macros and tables for the basic UV infrastructure.
      x86: define the macros and tables for blade functions
      x86: support for new UV apic
      x86: support for new UV apic, fix
      x86: UV startup of slave cpus

Jan Beulich (3):
      x86: prevent unconditional writes to DebugCtl MSR
      x86: simplify sync_test_bit()
      x86: bitops asm constraint fixes

Jan Kiszka (1):
      printk: don't prefer unsuited consoles on registration

Jeremy Fitzhardinge (39):
      xen: use iret instruction all the time
      x86: only enable interrupts when kernel state has been set up
      x86: simplify sync_test_bit(), improve
      x86: sparsemem: reduce i386 PAE section size
      x86: paravirt_ops: don't steal memory resources in paravirt_disable_iospace
      x86: convert pgalloc_64.h from macros to inlines
      x86: add common mm/pgtable.c
      x86: put paravirt stubs into common asm/pgalloc.h
      x86: move pte functions into common asm/pgalloc.h
      x86: move pmd functions into common asm/pgalloc.h
      x86: move pgalloc pud and pgd operations into common place
      x86: move all the pgd_list handling to one place
      x86: rename paravirt_alloc_pt etc after the pagetable structure
      x86: add pud_alloc for 4-level pagetables
      x86/pgtable.h: demacro ptep_set_access_flags
      x86/pgtable.h: demacro ptep_test_and_clear_young
      x86/pgtable.h: demacro ptep_clear_flush_young
      x86: demacro pgalloc paravirt stubs
      xen: use appropriate pte types
      xen: make use of pte_t union
      xen: unify pte operations
      xen: use phys_addr_t when referring to physical addresses
      xen: unify pte operations on machine frames
      xen: make sure iret faults are trapped
      x86: unify KERNEL_PGD_PTRS
      x86: unify pgd ctor/dtor
      xen: add support for callbackops hypercall
      xen: support sysenter/sysexit if hypervisor does
      xen: implement a debug-interrupt handler
      xen: make sure retriggered events are set pending
      xen: short-cut for recursive event handling
      xen: no need for domU to worry about MCE/MCA
      xen: jump to iret fixup
      xen/blkfront: use bdget_disk
      xen: disable preemption during tlb flush
      xen: allow set_pte_at on init_mm to be lockless
      xen: fold xen_sysexit into xen_iret
      xen: allow compilation with non-flat memory
      xen: add balloon driver

Jesper Juhl (1):
      x86 floppy: kill off the 'register' keyword from header

Jiri Slaby (3):
      x86: pgtable, document pde bits
      x86: fix exec mappings comments
      x86, generic: mark early_printk as asmlinkage

Joe Perches (146):
      x86: include/asm-x86/mutex_32.h - use angle brackets for include
      x86: arch/x86/kernel/cpu/feature_names.c - use angle brackets for include
      x86 - cleanup duplicate includes
      include/asm-x86/acpi.h: checkpatch cleanups - formatting only
      include/asm-x86/alternative.h: checkpatch cleanups - formatting only
      include/asm-x86/a.out-core.h: checkpatch cleanups - formatting only
      include/asm-x86/apicdef.h: checkpatch cleanups - formatting only
      include/asm-x86/apic.h: checkpatch cleanups - formatting only
      include/asm-x86/atomic_32.h: checkpatch cleanups - formatting only
      include/asm-x86/atomic_64.h: checkpatch cleanups - formatting only
      include/asm-x86/bitops_32.h: checkpatch cleanups - formatting only
      include/asm-x86/bitops_64.h: checkpatch cleanups - formatting only
      include/asm-x86/bitops.h: checkpatch cleanups - formatting only
      include/asm-x86/bug.h: checkpatch cleanups - formatting only
      include/asm-x86/byteorder.h: checkpatch cleanups - formatting only
      include/asm-x86/cacheflush.h: checkpatch cleanups - formatting only
      include/asm-x86/checksum_32.h: checkpatch cleanups - formatting only
      include/asm-x86/checksum_64.h: checkpatch cleanups - formatting only
      include/asm-x86/cmpxchg_32.h: checkpatch cleanups - formatting only
      include/asm-x86/cmpxchg_64.h: checkpatch cleanups - formatting only
      include/asm-x86/compat.h: checkpatch cleanups - formatting only
      include/asm-x86/current_32.h: checkpatch cleanups - formatting only
      include/asm-x86/current_64.h: checkpatch cleanups - formatting only
      include/asm-x86/desc_defs.h: checkpatch cleanups - formatting only
      include/asm-x86/desc.h: checkpatch cleanups - formatting only
      include/asm-x86/div64.h: checkpatch cleanups - formatting only
      include/asm-x86/dma.h: checkpatch cleanups - formatting only
      include/asm-x86/dwarf2_64.h: checkpatch cleanups - formatting only
      include/asm-x86/e820_32.h: checkpatch cleanups - formatting only
      include/asm-x86/e820_64.h: checkpatch cleanups - formatting only
      include/asm-x86/edac.h: checkpatch cleanups - formatting only
      include/asm-x86/efi.h: checkpatch cleanups - formatting only
      include/asm-x86/elf.h: checkpatch cleanups - formatting only
      include/asm-x86/fixmap_32.h: checkpatch cleanups - formatting only
      include/asm-x86/fixmap_64.h: checkpatch cleanups - formatting only
      include/asm-x86/floppy.h: checkpatch cleanups - formatting only
      include/asm-x86/futex.h: checkpatch cleanups - formatting only
      include/asm-x86/genapic_32.h: checkpatch cleanups - formatting only
      include/asm-x86/geode.h: checkpatch cleanups - formatting only
      include/asm-x86/highmem.h: checkpatch cleanups - formatting only
      include/asm-x86/hw_irq_64.h: checkpatch cleanups - formatting only
      include/asm-x86/hypertransport.h: checkpatch cleanups - formatting only
      include/asm-x86/i387.h: checkpatch cleanups - formatting only
      include/asm-x86/i8259.h: checkpatch cleanups - formatting only
      include/asm-x86/ia32.h: checkpatch cleanups - formatting only
      include/asm-x86/io_32.h: checkpatch cleanups - formatting only
      include/asm-x86/io_64.h: checkpatch cleanups - formatting only
      include/asm-x86/ioctls.h: checkpatch cleanups - formatting only
      include/asm-x86/io.h: checkpatch cleanups - formatting only
      include/asm-x86/ipcbuf.h: checkpatch cleanups - formatting only
      include/asm-x86/ipi.h: checkpatch cleanups - formatting only
      include/asm-x86/irq_32.h: checkpatch cleanups - formatting only
      include/asm-x86/irq_64.h: checkpatch cleanups - formatting only
      include/asm-x86/irqflags.h: checkpatch cleanups - formatting only
      include/asm-x86/kdebug.h: checkpatch cleanups - formatting only
      include/asm-x86/kexec.h: checkpatch cleanups - formatting only
      include/asm-x86/kprobes.h: checkpatch cleanups - formatting only
      include/asm-x86/kvm_host.h: checkpatch cleanups - formatting only
      include/asm-x86/kvm_x86_emulate.h: checkpatch cleanups - formatting only
      include/asm-x86/lguest_hcall.h: checkpatch cleanups - formatting only
      include/asm-x86/lguest.h: checkpatch cleanups - formatting only
      include/asm-x86/local.h: checkpatch cleanups - formatting only
      include/asm-x86/mc146818rtc.h: checkpatch cleanups - formatting only
      include/asm-x86/mca_dma.h: checkpatch cleanups - formatting only
      include/asm-x86/mmu_context_32.h: checkpatch cleanups - formatting only
      include/asm-x86/mmu_context_64.h: checkpatch cleanups - formatting only
      include/asm-x86/mmu.h: checkpatch cleanups - formatting only
      include/asm-x86/mmx.h: checkpatch cleanups - formatting only
      include/asm-x86/mmzone_32.h: checkpatch cleanups - formatting only
      include/asm-x86/mmzone_64.h: checkpatch cleanups - formatting only
      include/asm-x86/mpspec_def.h: checkpatch cleanups - formatting only
      include/asm-x86/mpspec.h: checkpatch cleanups - formatting only
      include/asm-x86/msidef.h: checkpatch cleanups - formatting only
      include/asm-x86/msr.h: checkpatch cleanups - formatting only
      include/asm-x86/mtrr.h: checkpatch cleanups - formatting only
      include/asm-x86/mutex_32.h: checkpatch cleanups - formatting only
      include/asm-x86/mutex_64.h: checkpatch cleanups - formatting only
      include/asm-x86/numa_64.h: checkpatch cleanups - formatting only
      include/asm-x86/numaq.h: checkpatch cleanups - formatting only
      include/asm-x86/page_32.h: checkpatch cleanups - formatting only
      include/asm-x86/page_64.h: checkpatch cleanups - formatting only
      include/asm-x86/param.h: checkpatch cleanups - formatting only
      include/asm-x86/paravirt.h: checkpatch cleanups - formatting only
      include/asm-x86/parport.h: checkpatch cleanups - formatting only
      include/asm-x86/pci_64.h: checkpatch cleanups - formatting only
      include/asm-x86/pci-direct.h: checkpatch cleanups - formatting only
      include/asm-x86/pci.h: checkpatch cleanups - formatting only
      include/asm-x86/pda.h: checkpatch cleanups - formatting only
      include/asm-x86/percpu.h: checkpatch cleanups - formatting only
      include/asm-x86/pgtable-2level.h: checkpatch cleanups - formatting only
      include/asm-x86/pgtable_32.h: checkpatch cleanups - formatting only
      include/asm-x86/pgtable-3level.h: checkpatch cleanups - formatting only
      include/asm-x86/pgtable_64.h: checkpatch cleanups - formatting only
      include/asm-x86/pgtable.h: checkpatch cleanups - formatting only
      include/asm-x86/posix_types_32.h: checkpatch cleanups - formatting only
      include/asm-x86/posix_types_64.h: checkpatch cleanups - formatting only
      include/asm-x86/processor.h: checkpatch cleanups - formatting only
      include/asm-x86/proto.h: checkpatch cleanups - formatting only
      include/asm-x86/ptrace.h: checkpatch cleanups - formatting only
      include/asm-x86/reboot.h: checkpatch cleanups - formatting only
      include/asm-x86/resume-trace.h: checkpatch cleanups - formatting only
      include/asm-x86/rio.h: checkpatch cleanups - formatting only
      include/asm-x86/rwsem.h: checkpatch cleanups - formatting only
      include/asm-x86/setup.h: checkpatch cleanups - formatting only
      include/asm-x86/sigcontext32.h: checkpatch cleanups - formatting only
      include/asm-x86/sigcontext.h: checkpatch cleanups - formatting only
      include/asm-x86/signal.h: checkpatch cleanups - formatting only
      include/asm-x86/smp_32.h: checkpatch cleanups - formatting only
      include/asm-x86/smp_64.h: checkpatch cleanups - formatting only
      include/asm-x86/spinlock.h: checkpatch cleanups - formatting only
      include/asm-x86/srat.h: checkpatch cleanups - formatting only
      include/asm-x86/string_32.h: checkpatch cleanups - formatting only
      include/asm-x86/string_64.h: checkpatch cleanups - formatting only
      include/asm-x86/suspend_32.h: checkpatch cleanups - formatting only
      include/asm-x86/suspend_64.h: checkpatch cleanups - formatting only
      include/asm-x86/swiotlb.h: checkpatch cleanups - formatting only
      include/asm-x86/sync_bitops.h: checkpatch cleanups - formatting only
      include/asm-x86/system.h: checkpatch cleanups - formatting only
      include/asm-x86/tce.h: checkpatch cleanups - formatting only
      include/asm-x86/thread_info_32.h: checkpatch cleanups - formatting only
      include/asm-x86/thread_info_64.h: checkpatch cleanups - formatting only
      include/asm-x86/tlbflush.h: checkpatch cleanups - formatting only
      include/asm-x86/topology.h: checkpatch cleanups - formatting only
      include/asm-x86/tsc.h: checkpatch cleanups - formatting only
      include/asm-x86/uaccess_32.h: checkpatch cleanups - formatting only
      include/asm-x86/uaccess_64.h: checkpatch cleanups - formatting only
      include/asm-x86/unaligned.h: checkpatch cleanups - formatting only
      include/asm-x86/unistd_32.h: checkpatch cleanups - formatting only
      include/asm-x86/unistd_64.h: checkpatch cleanups - formatting only
      include/asm-x86/user_32.h: checkpatch cleanups - formatting only
      include/asm-x86/user32.h: checkpatch cleanups - formatting only
      include/asm-x86/user_64.h: checkpatch cleanups - formatting only
      include/asm-x86/vdso.h: checkpatch cleanups - formatting only
      include/asm-x86/vga.h: checkpatch cleanups - formatting only
      include/asm-x86/vm86.h: checkpatch cleanups - formatting only
      include/asm-x86/vmi.h: checkpatch cleanups - formatting only
      include/asm-x86/voyager.h: checkpatch cleanups - formatting only
      include/asm-x86/xor_32.h: checkpatch cleanups - formatting only
      include/asm-x86/xor_64.h: checkpatch cleanups - formatting only
      include/asm-x86/ide.h: checkpatch cleanups - formatting only
      include/asm-x86/semaphore_32.h: checkpatch cleanups - formatting only
      include/asm-x86/semaphore_64.h: checkpatch cleanups - formatting only
      x86: include/asm-x86/pgalloc.h/bitops.h: checkpatch cleanups - formatting only
      include/asm-x86/string_32.h - style only
      x86: checkpatch cleanups - formatting only
      x86: include/asm-x86/pgalloc.h: checkpatch cleanups - formatting only

Johannes Weiner (1):
      x86: Remove redundant display of free swap space in show_mem()

Mark McLoughlin (3):
      xen: Module autoprobing support for frontend drivers
      xen: Add compatibility aliases for frontend drivers
      x86: move dma_supported and dma_set_mask to pci-dma_32.c

Markus Armbruster (3):
      xen: make hvc0 the preferred console in domU
      xen: Make xen-blkfront write its protocol ABI to xenstore
      xen pvfb: Para-virtual framebuffer, keyboard and pointer driver

Markus Metzger (1):
      x86, ptrace: PEBS support

Mathieu Desnoyers (3):
      x86: enhance DEBUG_RODATA support - alternatives
      x86 - Enhance DEBUG_RODATA support for hotplug and kprobes
      x86: fix test_poke for vmalloced pages

Mikael Pettersson (1):
      x86: correct/clarify comment in nops.h

Mike Galbraith (1):
      sched: make !hrtick faster

Mike Travis (23):
      x86: clean up non-smp usage of cpu maps
      cpumask: add cpumask_scnprintf_len function
      x86: reduce memory and stack usage in intel_cacheinfo
      x86: oprofile: remove NR_CPUS arrays in arch/x86/oprofile/nmi_int.c
      asm-generic: add node_to_cpumask_ptr macro
      numa: move large array from stack to _initdata section
      cpumask: Cleanup more uses of CPU_MASK and NODE_MASK
      x86: modify Kconfig to allow up to 4096 cpus
      init: move setup of nr_cpu_ids to as early as possible v3
      sched: add new set_cpus_allowed_ptr function
      sched: remove fixed NR_CPUS sized arrays in kernel_sched_c v2
      x86: use new set_cpus_allowed_ptr function
      generic: use new set_cpus_allowed_ptr function
      cpuset: modify cpuset_set_cpus_allowed to use cpumask pointer
      generic: reduce stack pressure in sched_affinity
      nodemask: use new node_to_cpumask_ptr function
      cpumask: reduce stack usage in SD_x_INIT initializers
      cpumask: add CPU_MASK_ALL_PTR macro
      x86: convert cpumask_of_cpu macro to allocated array
      x86: modify show_shared_cpu_map in intel_cacheinfo
      cpumask: use new cpus_scnprintf function
      cpumask: add show cpu map functions
      sched: remove another cpumask_t variable from stack

Nick Andrew (2):
      printk: refactor processing of line severity tokens
      printk: remember the message level for multi-line output

Olof Johansson (1):
      tasklets: execute tasklets in the same order they were queued

Paolo Ciarrocchi (42):
      x86: coding style fixes for arch/x86/kernel/cpu/centaur.c
      x86: coding style fixes to arch/x86/lib/memmove_64.c
      x86: coding style fixes to arch/x86/kernel/syscall_64.c
      x86: coding style fixes to arch/x86/lib/string_32.c
      x86: coding style fixes to arch/x86/kernel/cpu/mcheck/p5.c
      x86: coding style fixes to arch/x86/kernel/x8664_ksyms_64.c
      x86: coding style fixes to arch/x86/oprofile/op_model_ppro.c
      x86: coding style fixes to arch/x86/oprofile/op_model_athlon.c
      x86: coding style fixes to arch/x86/mach-generic/probe.c
      x86: coding style fixes to arch/x86/mach-generic/default.c
      x86: coding style fixes to arch/x86/mach-generic/summit.c
      x86: coding style fixes to arch/x86/kernel/cpu/nexgen.c
      x86: coding style fixes to arch/x86/mach-generic/bigsmp.c
      x86: coding style fixes to arch/x86/kernel/cpu/mcheck/p6.c
      x86: coding style fixes to arch/x86/kernel/cpu/umc.c
      x86: coding style fixes to arch/x86/boot/compressed/misc.c
      x86: coding style fix to arch/x86/boot/pm.c
      x86: coding style fixes to arch/x86/kernel/summit_32.c
      x86: coding style fixes to arch/x86/kernel/cpu/intel.c
      x86: coding style fixes to arch/x86/oprofile/init.c
      x86: coding style fixes to arch/x86/lib/strstr_3
      x86: coding style fixes to arch/x86/kernel/mca_32.c
      x86: coding style fixes to arch/x86/kernel/cpu/mtrr/state.c
      x86: coding style fixes to arch/x86/lib/memcpy_32.c
      x86: coding style fixes to arch/x86/kernel/cpu/transmeta.c
      x86: coding style fixes to arch/x86/kernel/cpu/amd.c
      x86: coding style fixes to arch/x86/kernel/vm86_32.c
      x86: coding style fixes to arch/x86/kernel/cpu/mcheck/non-fatal.c
      x86: coding style fixes to arch/x86/kernel/cpu/mcheck/winchip.c
      x86: coding style fixes to arch/x86/kernel/cpu/mcheck/mce_32.c
      x86: coding style fixes to arch/x86/boot/cpucheck.c
      x86: coding style fixes to arch/x86/kernel/cpu/cyrix.c
      x86: coding style fixes to arch/x86/oprofile/nmi_timer_int.c
      x86: coding style fixes to arch/x86/kernel/msr.c
      x86: coding style fixes to arch/x86/xen/multicalls.c
      x86: coding style fixes to arch/x86/power/cpu_32.c
      x86: coding style fixes to arch/x86/kernel/cpu/common.c
      x86: coding style fixes to arch/x86/lib/usercopy_32.c
      x86: coding style fixes to arch/x86/kernel/early_printk.c
      x86: coding style fixes to x86/kernel/early_printk.c
      x86: coding style fixes to arch/x86/kernel/setup_32.c
      x86: coding style fixes to arch/x86/kernel/acpi/sleep.c

Paul E. McKenney (5):
      rcu: add call_rcu_sched()
      rcu: add memory barriers and comments to rcu_check_callbacks()
      rcu: add rcu_barrier_sched() and rcu_barrier_bh()
      rcu: add call_rcu_sched() and friends to rcutorture
      1Q08 RCU doc update, add call_rcu_sched()

Pavel Machek (8):
      x86: wmb() confusion in system.h
      iommu: it could use some documentation
      x86: clean up aperture_64.c
      x86: fix iommu breaks usb after hibernation resume
      x86: iommu: use symbolic constants, not hardcoded numbers
      x86: clean up =0 initializations in arch/x86/kernel/tsc_32.c
      x86: move suspend wakeup code to C
      x86 gart: factor out common code

Pekka Enberg (2):
      x86: __show_registers() and __show_regs() API unification
      kmemcheck: support for x86-64

Pekka J Enberg (1):
      kmemcheck: use pte helpers instead of ->pte_low

Pekka Paalanen (16):
      x86: add a list for custom page fault handlers.
      x86: mmiotrace - trace memory mapped IO
      x86 mmiotrace: use lookup_address()
      x86 mmiotrace: fix relay-buffer-full flag for SMP
      x86 mmiotrace: comment about user space ABI
      x86: explicit call to mmiotrace in do_page_fault()
      x86 mmiotrace: Use percpu instead of arrays.
      x86: mmiotrace full patch, preview 1
      x86: mmiotrace, preview 2
      tracing and mmiotrace
      tracing and mmiotrace
      tracing and mmiotrace
      x86 mmiotrace: move files into arch/x86/mm/.
      x86 mmiotrace: remove ISA_trace parameter.
      x86 mmiotrace: Do not print bogus pid
      mmiotrace: add user documentation

Peter Zijlstra (12):
      sched: fix wakeup granularity for buddies
      sched: work around hrtick related lockup
      sched: fix regression with sched yield
      sched: rt-group: synchonised bandwidth period
      sched: rt-group: smp balancing
      ftrace: trace next state
      ftrace: fix wakeup callback
      sched: old sleeper bonus
      sched: remove isolcpus
      cpuset: system sets
      genirq: system set irq affinities
      kthread: system set kthread affinities

Randy Dunlap (4):
      x86: fix VisualWS and Voyager kexec build failures
      x86: fix arch/x86/mm/ioremap.c warning
      x86: fix printk format
      x86/mmiotrace: uses/depends on PCI

Ravikiran G Thirumalai (5):
      x86: vSMP: Fix is_vsmp_box()
      x86: fix build breakage when PCI is define and PARAVIRT is not
      x86: vSMP: use pvops only if platform has the capability to support it
      x86: apic_is_clustered_box to indicate unsynched TSC's on multiboard vSMP systems
      x86: clean up vSMP detection

Reynes Philippe (1):
      sched: sched.c needs tick.h

Robert Hancock (1):
      x86: validate against acpi motherboard resources

Robert P. J. Day (1):
      x86: Explicitly include required header files.

Robert Richter (1):
      x86: apic: extended interrupt LVT support for AMD

Roland McGrath (8):
      x86 vDSO: don't use disabled vDSO for signal trampoline
      x86 vdso: don't map 32-bit vdso when disabled
      x86: ia32 ptrace vs -ENOSYS
      x86: ptrace vs -ENOSYS
      x86: ia32 ptrace vs -ENOSYS sysenter/syscall
      x86: sys32_execve PT_DTRACE
      x86: handle_vm86_trap cleanup
      x86 vDSO: compile with -g, 64-bit

Roman Zippel (1):
      x86: fix recursive dependencies

Rusty Russell (1):
      x86: if we cannot calibrate the TSC, we panic.

Soeren Sandmann Pedersen (2):
      ftrace: allow the event pipe to be polled
      sysprof: kernel trace

Steven Rostedt (58):
      ftrace: add notrace annotations for NMI routines
      ftrace: make the task state char-string visible to all
      ftrace: add preempt_enable/disable notrace macros
      x86: add notrace annotations to vsyscall.
      ftrace: latency tracer infrastructure
      ftrace: function tracer
      ftrace: add tracing of context switches
      ftrace: tracer for scheduler wakeup latency
      ftrace: trace irq disabled critical timings
      ftrace: trace preempt off critical timings
      ftrace: dynamic enabling/disabling of function calls
      ftrace: add ftrace_enabled sysctl to disable mcount function
      ftrace: use nops instead of jmp
      ftrace: move memory management out of arch code
      ftrace: use dynamic patching for updating mcount calls
      ftrace: add filter select functions to trace
      ftrace: convert single large buffer into single pages.
      ftrace: debug smp_processor_id, use notrace preempt disable
      ftrace: irqs off smp_processor_id() fix
      ftrace: lockdep notrace annotations
      ftrace: don't use raw_local_irq_save/restore
      ftrace: fix updates to max trace
      ftrace: fix max latency
      ftrace: force recording
      ftrace: self-tests
      ftrace: startup tester on dynamic tracing.
      ftrace: disable all tracers on corrupted buffer
      ftrace: reset selftests
      ftrace: change buffers to producer consumer
      trace - add a buffer for output
      ftrace: user run time file reading
      ftrace: pipe fixes
      ftrace - fix dynamic ftrace memory leak
      ftrace: disable tracing on failure
      ftrace: enabled tracing by default
      ftrace: add trace_function api for other tracers to use
      rcupreempt: remove duplicate prototypes
      ftrace: remove address of function names
      ftrace: do not profile lib/string.o
      ftrace: remove wakeup from function trace
      ftrace: printk and trace irqsoff and wakeups
      ftrace: add TRACE_STACK and TRACE_SPECIAL to selftest validation
      ftrace: fix dynamic ftrace selftest
      ftrace: irqsoff use raw_smp_processor_id
      ftrace: user raw_spin_lock in tracing
      ftrace: remove function tarcing from spinlock debug
      ftrace: use Makefile to remove tracing from lockdep
      ftrace: add UNINTERRUPTIBLE state for kftraced on disable
      ftrace: fix mutex unlock in trace output
      ftrace: selftest protect againt max flip
      ftrace: fix the fault label in updating code
      ftrace: dont write protect kernel text
      ftrace: allow trace_pipe to block on all reads
      ftrace: restore iterator trace in pipe read
      ftrace: return EOF in trace_pipe on change of tracer
      ftrace: trace_pipe implement NONBLOCK
      ftrace: user proper API for setting RT prios in selftest
      ftrace: trace_entries to dynamically change trace buffer size

Suresh Siddha (5):
      srat, x86: add support for nodes spanning other nodes
      x86, fpu: split FPU state from task struct - v5
      x86, fpu: lazy allocation of FPU area - v5
      x86: fpu xstate split cleanup
      x86: fpu xstate split fix

Tejun Heo (1):
      printk: clean up recursion check related static variables

Thomas Gleixner (8):
      x86: add debug info to DEBUG_PAGEALLOC
      cpa-debug-debugfs.patch
      pagetable-dumper-debugfs.patch
      x86: check physical address range in ioremap
      x86: replace the now useless max_pfn_mapped define
      input: fix PIT build bug on ppc64
      generic: find_next_bit() fix
      x86: tsc prevent time going backwards

Thomas Petazzoni (1):
      x86: use ELF section to list CPU vendor specific code

Vegard Nossum (7):
      x86: kmemcheck, v6
      x86: kmemcheck v7
      kmemcheck: check PTE before calling virt_to_page() on the address
      x86, kmemcheck: simplify shadow-address lookup logic
      kmemcheck: correct decoded size of movzbl instruction
      kmemcheck: one-shot mode
      x86: allocate fpu contexts with SLAB_NOTRACK flag

Venki Pallipadi (4):
      devmem: add range_is_allowed() check to mmap of /dev/mem
      x86: PAT bug fix for attribute type check after reserve_memtype
      x86: PAT infrastructure patch, documentation updates
      x86: PAT bug fix for attribute type check after reserve_memtype, debug

WANG Cong (1):
      x86: remove pointless comments

Yakov Lerner (1):
      x86, kprobes: correct post-eip value in post_hander()

Yinghai Lu (61):
      x86: clean up find_e820_area(), 64-bit
      x86_64: get apic_id later in acpi_numa_processor_affinity_init
      x86_64: remove never used nodenumer in pda
      x86: make amd quad core 8 socket system not be clustered_box, #2
      x86: clean up e820_reserve_resources on 64-bit
      x86_64: insert_resorce for lapic addr after e820_reserve_resources
      x86: apic_is_clustered_box for vsmp
      x86: remove wrong setting about CONSTANT_TSC for intel cpu
      x86_64: fix amd_detect_cmp
      x86: show apicid for cpu in proc
      x86: introduce initial apicid
      x86: sort address_markers for dump_pagetables
      x86_64: get boot_cpu_id as early for k8_scan_nodes
      x86: early memtest to find bad ram
      x86: allocate e820 resource struct all together
      smpboot integration
      x86: memtest bootparam
      x86: fix memtest print out
      x86: enable PAT for amd k8 and fam10h
      x86: pat cpu feature bit setting for known cpus
      x86: print out buggy mptable
      x86_64: do not reserve ramdisk two times
      x86: cleanup: change _end to end_before_pgt
      mm: make mem_map allocation continuous
      mm: fix alloc_bootmem_core to use fast searching for all nodes
      x86: clear pci_mmcfg_virt when mmcfg get rejected
      x86: mmconf enable mcfg early
      x86_64: set cfg_size for AMD Family 10h in case MMCONFIG
      x86_64: check and enable MMCONFIG for AMD Family 10h
      x86_64: check MSR to get MMCONFIG for AMD Family 10h
      x86: if acpi=off, force setting the mmconf for fam10h
      x86: seperate mmconf for fam10h out from setup_64.c
      try parent numa_node at first before using default v2
      x86: skip it if Fam 10h only handle bus 0
      ide: use dev_to_node instead of pcibus_to_node
      x86: remove unneeded check in mmconf reject
      mm: offset align in alloc_bootmem v3
      mm: make reserve_bootmem can crossed the nodes
      x86_64: make reserve_bootmem_generic to use new reserve_bootmem
      x86_64: fix setup_node_bootmem to support big mem excluding with memmap
      x86 pci: remove checking type for mmconfig probe v2
      x86: change pci_direct_conf1 back not static
      x86: reserve dma32 early for gart
      x86: get mp_bus_to_node early
      x86: use bus conf in NB conf fun1 to get bus range on, on 64-bit
      x86: multi pci root bus with different io resource range, on 64-bit
      x86/acpi: make dev_to_node return online node
      x86: double check the multi root bus with fam10h mmconf
      x86/pci: add pci=skip_isa_align command lines.
      net: use numa_node in net_devcice->dev instead of parent
      x86_64: don't need set default res if only have one root bus
      x86_64/mm: check and print vmemmap allocation continuous
      x86_64/mm: check and print vmemmap allocation continuous -fix
      acpi: get boot_cpu_id as early for k8_scan_nodes
      x86: work around io allocation overlap of HT links
      x86: agp_gart size checking for buggy device
      x86: checking aperture size order
      x86: add pci=check_enable_amd_mmconf and dmi check
      x86 PCI: call dmi_check_pciprobe()
      x86_64: allocate gart aperture from 512M
      PCI: use dev_to_node in pci_call_probe

gorcunov@gmail.com (6):
      x86: relocate_kernel_32.S - clear register in more elegant way
      x86: relocate_kernel - use PAGE_SIZE instead of numeric constant
      x86: relocate_kernel - use predefined macroses for processor state
      x86: relocate_kernel - use predefined macroses for page attributes
      x86: cleanup - rename VM_MASK to X86_VM_MASK
      x86: replace most VM86 flags with flags from processor-flags.h

stephane eranian (3):
      x86: add cpu_has_arch_perfmon
      x86: add AMD Northbridge MSR definition
      x86: add AMD Northbridge PCI Id

venkatesh.pallipadi@intel.com (13):
      x86: PAT documentation
      x86: PAT infrastructure patch
      x86: PAT avoid aliasing in /dev/mem read/write
      x86: PAT make ioremap_change_attr non-static
      x86: PAT use reserve free memtype in ioremap and iounmap
      x86: PAT use reserve free memtype in set_memory_uc
      x86: PAT use reserve free memtype in pci_mmap_page_range
      x86: PAT phys_mem_access_prot_allowed for dev/mem mmap
      x86: PAT use reserve free memtype in mmap of /dev/mem
      x86: PAT add set_memory_wc() interface
      x86: PAT add ioremap_wc() interface
      x86: add PAT related debug prints
      x86: PAT export resource_wc in pci sysfs


^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17 19:43                 ` Andrew Morton
@ 2008-04-17 20:39                   ` Vegard Nossum
  2008-04-17 20:55                     ` Andrew Morton
  0 siblings, 1 reply; 71+ messages in thread
From: Vegard Nossum @ 2008-04-17 20:39 UTC (permalink / raw)
  To: Andrew Morton; +Cc: mingo, linux-kernel, torvalds, tglx, hpa, Pekka Enberg

Hi Andrew,

Thank you very much for the review of this patch. Those are hard to
come by, and I've posted kmemcheck to LKML already 3 or 4 times, with
relatively sparse response. I mean, the fact that they were ALL
whitespace damaged, but discovered by nobody, quite plainly tells me
that nobody actually tried to apply it (except perhaps Daniel Walker,
but we never realized it was whitespace damage causing the problems).
The patches that Ingo took into x86 were probably sent as an
attachment...

On Thu, Apr 17, 2008 at 9:43 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Thu, 17 Apr 2008 20:47:06 +0200
>
> "Vegard Nossum" <vegard.nossum@gmail.com> wrote:
>  > Actually it doesn't. I attach a patch which gets rid of the page flag,
>  > and we rely instead on the PTE flag for page-trackedness.
>  >
>  > The reason we didn't do this at once is that the making of kmemcheck
>  > has been pretty much my first introduction to SLUB, x86, page flags,
>  > etc., and the actual semantics of the various introduced flags have
>  > varied since the first version of kmemcheck. At this point, the struct
>  > page flags weren't actually needed anymore, but they were convenient.
>  >
>  > My apologies for not inlining the patch -- I don't have a mail client
>  > that won't mess up whitespace. It can also be downloaded at:
>  > http://folk.uio.no/vegardno/linux/0001-kmemcheck-remove-use-of-tracked-page-flag.patch
>  >
>  > The patch has received minimal amount of testing, but I've
>  > double-checked the logic. It boots fine on my laptop, boot log at:
>  > http://folk.uio.no/vegardno/linux/kmemcheck-20080417.txt
>  >
>  > Ingo, will you take this for some additional testing?
>  >
>
>  If you're OK with doing it this way then it would be preferable.
>
>  > diff --git a/arch/x86/kernel/kmemcheck.c b/arch/x86/kernel/kmemcheck.c
>  > index 16dce10..d82f35d 100644
>  > --- a/arch/x86/kernel/kmemcheck.c
>  > +++ b/arch/x86/kernel/kmemcheck.c
>  > @@ -233,12 +233,27 @@ param_kmemcheck(char *str)
>  >       if (!str)
>  >               return -EINVAL;
>  >
>  > -     sscanf("%d", str, &kmemcheck_enabled);
>  > +     sscanf(str, "%d", &kmemcheck_enabled);
>  >       return 0;
>  >  }
>
>  whoops.  Note to Ingo: unrelated bugfix in there.

Yes, sorry. I had actually already e-mailed this as a separate patch
to Ingo before sending this to the list, so he should know. But it
should not have been part of this patch, I agree.

>  >  early_param("kmemcheck", param_kmemcheck);
>
>  kmemcheck= is documented in at least three places, which is nice, but it
>  isn't mentioned in the place where we document kernel-parameters:
>  Documentation/kernel-parameters.txt.  A brief section there which directs
>  the user to the extended docs would be fine.
>
>  early_param() is unusual - we normally use __setup().  I assume there's a
>  reason for using early_param(), but that reason cannot be discerned from
>  reading the code.  A /*comment*/ is the way to fix that.

The reason is that we need to set this before kmalloc() is ever
called. A comment will come.

But it seems that __setup() is what is really missing a comment. I
don't know what it is or how it works, and the comments around the
definition are not very helpful. Maybe somebody could enlighten me?

>  > +static pte_t *
>  > +address_get_pte(unsigned int address)
>
>  This is not the preferred way of laying out function declarations but I've
>  basically given up on this one.
>
>         (void *)address
>
>  is more common, but I'm close to giving up on that too.
>
>  >  static int
>  > -show_addr(uint32_t addr)
>  > +show_addr(uint32_t address)
>
>  u32 is preferred, but ditto.

This will be turned into unsigned long with 64-bit support. (Hopefully
we can get that working too.)

Changing these to match the rest of the kernel is no problem for me.
It is not the way I would write it, but Pekka and Ingo has already
forced me to write if () instead of if(), so there should be no reason
to stop here! :-)

>  Perhaps we should get all this code onto the list(s) for re-review.  It's
>  been a while..

I'm not sure it would make much of a difference, except perhaps for
you, if you want to review it all. (My latest post to LKML had 0
replies in total. Well, except private e-mail exchange with Ingo and
Pekka; they should know the code already. Once again, thanks to them
for helping me.) Do you still want me to post it again?

Thank  you.


Vegard

PS: And it's not that I do that much testing/reviewing myself. But I
do think I have the excuse of being a newbie at this :-)

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17 20:39                   ` Vegard Nossum
@ 2008-04-17 20:55                     ` Andrew Morton
  0 siblings, 0 replies; 71+ messages in thread
From: Andrew Morton @ 2008-04-17 20:55 UTC (permalink / raw)
  To: Vegard Nossum; +Cc: mingo, linux-kernel, torvalds, tglx, hpa, penberg

On Thu, 17 Apr 2008 22:39:55 +0200
"Vegard Nossum" <vegard.nossum@gmail.com> wrote:

> Hi Andrew,
> 
> Thank you very much for the review of this patch. Those are hard to
> come by, and I've posted kmemcheck to LKML already 3 or 4 times, with
> relatively sparse response. I mean, the fact that they were ALL
> whitespace damaged, but discovered by nobody, quite plainly tells me
> that nobody actually tried to apply it (except perhaps Daniel Walker,
> but we never realized it was whitespace damage causing the problems).
> The patches that Ingo took into x86 were probably sent as an
> attachment...

hm.  Our review problem is well-understood.

> to Ingo before sending this to the list, so he should know. But it
> should not have been part of this patch, I agree.
> 
> >  >  early_param("kmemcheck", param_kmemcheck);
> >
> >  kmemcheck= is documented in at least three places, which is nice, but it
> >  isn't mentioned in the place where we document kernel-parameters:
> >  Documentation/kernel-parameters.txt.  A brief section there which directs
> >  the user to the extended docs would be fine.
> >
> >  early_param() is unusual - we normally use __setup().  I assume there's a
> >  reason for using early_param(), but that reason cannot be discerned from
> >  reading the code.  A /*comment*/ is the way to fix that.
> 
> The reason is that we need to set this before kmalloc() is ever
> called. A comment will come.
> 
> But it seems that __setup() is what is really missing a comment. I
> don't know what it is or how it works, and the comments around the
> definition are not very helpful. Maybe somebody could enlighten me?

It makes my head spin too.  Reading through the first bit of
init/main.c:start_kernel() is your best hope, sorry.

> >  > +static pte_t *
> >  > +address_get_pte(unsigned int address)
> >
> >  This is not the preferred way of laying out function declarations but I've
> >  basically given up on this one.
> >
> >         (void *)address
> >
> >  is more common, but I'm close to giving up on that too.
> >
> >  >  static int
> >  > -show_addr(uint32_t addr)
> >  > +show_addr(uint32_t address)
> >
> >  u32 is preferred, but ditto.
> 
> This will be turned into unsigned long with 64-bit support. (Hopefully
> we can get that working too.)
> 
> Changing these to match the rest of the kernel is no problem for me.
> It is not the way I would write it, but Pekka and Ingo has already
> forced me to write if () instead of if(), so there should be no reason
> to stop here! :-)

These things are OK as-is, I think.  It'd be somewhat less nice in
situations where newly-added code was inconsistent with surrounding
existing code but it's still hardly a huge problem.

> >  Perhaps we should get all this code onto the list(s) for re-review.  It's
> >  been a while..
> 
> I'm not sure it would make much of a difference, except perhaps for
> you, if you want to review it all. (My latest post to LKML had 0
> replies in total. Well, except private e-mail exchange with Ingo and
> Pekka; they should know the code already. Once again, thanks to them
> for helping me.) Do you still want me to post it again?

mm...  I wouldn't mind taking a closer look at it all.  That documentation
file makes it _much_ easier to review the code, and the review becomes more
effective than it would otherwise be.

> 
> PS: And it's not that I do that much testing/reviewing myself. But I
> do think I have the excuse of being a newbie at this :-)

You're in good company ;)

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-16 20:23 [v2.6.26] what's brewing in x86.git for v2.6.26 Ingo Molnar
                   ` (3 preceding siblings ...)
  2008-04-17  7:48 ` Andrew Morton
@ 2008-04-18  6:27 ` Andrew Morton
  2008-04-18  6:38   ` David Miller
  4 siblings, 1 reply; 71+ messages in thread
From: Andrew Morton @ 2008-04-18  6:27 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel, Arjan van de Ven

On Wed, 16 Apr 2008 22:23:38 +0200 Ingo Molnar <mingo@elte.hu> wrote:

> Arjan van de Ven (6):
>	...
>       x86: mark init_mm deprecated

Why can't I find this patch on the mailing list?

It's an MM patch which touches sched.h.  It should not be in git-x86.

It generates over a megabyte of warnings on sparc64.

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-18  6:27 ` Andrew Morton
@ 2008-04-18  6:38   ` David Miller
  2008-04-18  7:47     ` Ingo Molnar
  0 siblings, 1 reply; 71+ messages in thread
From: David Miller @ 2008-04-18  6:38 UTC (permalink / raw)
  To: akpm; +Cc: mingo, linux-kernel, arjan

From: Andrew Morton <akpm@linux-foundation.org>
Date: Thu, 17 Apr 2008 23:27:47 -0700

> On Wed, 16 Apr 2008 22:23:38 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> 
> > Arjan van de Ven (6):
> >	...
> >       x86: mark init_mm deprecated
> 
> Why can't I find this patch on the mailing list?
> 
> It's an MM patch which touches sched.h.  It should not be in git-x86.
> 
> It generates over a megabyte of warnings on sparc64.

If you're going to touch generic code, test build on other
platforms or get it into a tree where such build testing is
done for you.

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-18  6:38   ` David Miller
@ 2008-04-18  7:47     ` Ingo Molnar
  2008-04-18  8:00       ` Andrew Morton
  0 siblings, 1 reply; 71+ messages in thread
From: Ingo Molnar @ 2008-04-18  7:47 UTC (permalink / raw)
  To: David Miller; +Cc: akpm, linux-kernel, arjan


* David Miller <davem@davemloft.net> wrote:

> From: Andrew Morton <akpm@linux-foundation.org>
> Date: Thu, 17 Apr 2008 23:27:47 -0700
> 
> > On Wed, 16 Apr 2008 22:23:38 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> > 
> > > Arjan van de Ven (6):
> > >	...
> > >       x86: mark init_mm deprecated
> > 
> > Why can't I find this patch on the mailing list?
> > 
> > It's an MM patch which touches sched.h.  It should not be in 
> > git-x86. It generates over a megabyte of warnings on sparc64.
> 
> If you're going to touch generic code, test build on other platforms 
> or get it into a tree where such build testing is done for you.

we do an automatic build test (of both vmlinux and of modules) of over 
80 non-x86 architecture configs, amongst them are sparc64 and sparc 
configs:

  http://www.tglx.de/autoqa-cgi/index?run=86&tree=1

for the latest version of our trees all the 80 non-x86 configs (and all 
96 configs in total) built successfully.

if in the sparc64 row you click on the green "OK" button (which signals 
that the build was successful) you can get the build log and see all 7 
warnings that get triggered on the sparc64 defconfig with 
sched-devel/latest [which embedds x86/latest].

so i'm not sure where those "over a megabyte of warnings" come from.

	Ingo

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-18  7:47     ` Ingo Molnar
@ 2008-04-18  8:00       ` Andrew Morton
  2008-04-18  8:11         ` Christoph Hellwig
  0 siblings, 1 reply; 71+ messages in thread
From: Andrew Morton @ 2008-04-18  8:00 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: David Miller, linux-kernel, arjan

On Fri, 18 Apr 2008 09:47:42 +0200 Ingo Molnar <mingo@elte.hu> wrote:

> so i'm not sure where those "over a megabyte of warnings" come from.

allmodconfig.

In file included from include/linux/mm.h:39,
                 from include/linux/scatterlist.h:6,
                 from include/asm/dma-mapping.h:4,
                 from include/linux/dma-mapping.h:52,
                 from include/asm/pci.h:6,
                 from include/linux/pci.h:945,
                 from drivers/ata/ata_generic.c:21:
include/asm/pgtable.h: In function `set_pte_at':
include/asm/pgtable.h:670: warning: `init_mm' is deprecated (declared at include/linux/sched.h:1616)

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-18  8:00       ` Andrew Morton
@ 2008-04-18  8:11         ` Christoph Hellwig
  2008-04-18  8:18           ` David Miller
  0 siblings, 1 reply; 71+ messages in thread
From: Christoph Hellwig @ 2008-04-18  8:11 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Ingo Molnar, David Miller, linux-kernel, arjan

On Fri, Apr 18, 2008 at 01:00:08AM -0700, Andrew Morton wrote:
> On Fri, 18 Apr 2008 09:47:42 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> 
> > so i'm not sure where those "over a megabyte of warnings" come from.
> 
> allmodconfig.
> 
> In file included from include/linux/mm.h:39,
>                  from include/linux/scatterlist.h:6,
>                  from include/asm/dma-mapping.h:4,
>                  from include/linux/dma-mapping.h:52,
>                  from include/asm/pci.h:6,
>                  from include/linux/pci.h:945,
>                  from drivers/ata/ata_generic.c:21:
> include/asm/pgtable.h: In function `set_pte_at':
> include/asm/pgtable.h:670: warning: `init_mm' is deprecated (declared at include/linux/sched.h:1616)

Why is is deprecated anyway?  I think we all agreed that killing the
export is good, but I don't see any way how we could kill the core
useage.

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-18  8:11         ` Christoph Hellwig
@ 2008-04-18  8:18           ` David Miller
  2008-04-18 12:48             ` Ingo Molnar
  0 siblings, 1 reply; 71+ messages in thread
From: David Miller @ 2008-04-18  8:18 UTC (permalink / raw)
  To: hch; +Cc: akpm, mingo, linux-kernel, arjan

From: Christoph Hellwig <hch@infradead.org>
Date: Fri, 18 Apr 2008 04:11:21 -0400

> On Fri, Apr 18, 2008 at 01:00:08AM -0700, Andrew Morton wrote:
> > On Fri, 18 Apr 2008 09:47:42 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> > 
> > > so i'm not sure where those "over a megabyte of warnings" come from.
> > 
> > allmodconfig.
> > 
> > In file included from include/linux/mm.h:39,
> >                  from include/linux/scatterlist.h:6,
> >                  from include/asm/dma-mapping.h:4,
> >                  from include/linux/dma-mapping.h:52,
> >                  from include/asm/pci.h:6,
> >                  from include/linux/pci.h:945,
> >                  from drivers/ata/ata_generic.c:21:
> > include/asm/pgtable.h: In function `set_pte_at':
> > include/asm/pgtable.h:670: warning: `init_mm' is deprecated (declared at include/linux/sched.h:1616)
> 
> Why is is deprecated anyway?  I think we all agreed that killing the
> export is good, but I don't see any way how we could kill the core
> useage.

set_pte_at() is done inside drivers and what-not, you're not
going to be able to get rid of this export so easily.

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17 10:06   ` Alexander van Heukelum
  2008-04-17 10:51     ` Andi Kleen
@ 2008-04-18  8:38     ` Ingo Molnar
  2008-04-18 10:51       ` Andi Kleen
  1 sibling, 1 reply; 71+ messages in thread
From: Ingo Molnar @ 2008-04-18  8:38 UTC (permalink / raw)
  To: Alexander van Heukelum
  Cc: Andi Kleen, linux-kernel, Thomas Gleixner, H. Peter Anvin


* Alexander van Heukelum <heukelum@fastmail.fm> wrote:

> My conclusion would be: the speed of the generic bitmap implementation 
> is either better than or at least comparable to the current private 
> implementations in i386/x86_64. The generic version is out-of-line, 
> while the private implementation of i386 was inlined: this causes a 
> regression for very small bitmaps. However, if the bitmap size is a 
> constant and fits a long integer, the updated generic code should 
> inline an optimized version, like x86_64 currently does it.
> 
> I think the change is a good one.

quite so. Your change was promising from the get go and the latest 
iteration was definitely a good one and is very much mergable. That it 
also helps improve other architectures is the icing on the cake.

Andi will have to prove his points by coming up with competing benchmark 
results - you certainly did your fair share to back up your change with 
numbers. (and Andi, if/when you do so, please Cc: Alexander too in the 
future. Dont you want him to be able to reply to your complaints ASAP?)

I dont really understand the negativism that comes from Andi - he was 
very much aware of the various iterations and benchmarks you did when 
developing this rather cool feature: he participated in those threads 
and was Cc:-ed as well. The "100% bogus benchmark with the most 
unrealistic input data set one can imagine" remark from Andi with no Cc: 
was a nasty and unprovoked hit below the waistline.

	Ingo

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17 18:51                 ` Ingo Molnar
  2008-04-17 19:57                   ` Andrew Morton
@ 2008-04-18  9:33                   ` Tomasz Kłoczko
  2008-04-18  9:42                     ` Ingo Molnar
  1 sibling, 1 reply; 71+ messages in thread
From: Tomasz Kłoczko @ 2008-04-18  9:33 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Andrew Morton, Christoph Hellwig, Pekka Enberg, linux-kernel,
	Linus Torvalds, Arjan van de Ven

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2128 bytes --]

On Thu, 17 Apr 2008, Ingo Molnar wrote:

>
> * Andrew Morton <akpm@linux-foundation.org> wrote:
>
>> afaik the sysprof-vs-oprofile issue still hasn't been settled.  Maybe
>> it's no longer a relevant question with the new code - I just don't
>> know. Everything went all quiet and then this stuff happened.
>
> i dont think there's any big issue here. Sysprof is a time and stack
> system-wide tracer/profiler, oprofile profiles CPU events - deep
> stacktracing is an afterthought there. And how do you set up oprofile to
> do precise time events?
>
> with sysprof you can do:
>
>  cd /sys/kernel/debug/tracing
>  echo sysprof > current_tracer
>  cat trace_pipe
>
> and you'll see the trace events go by, live. The user-space bits of
> sysprof have been ported over to ftrace/sysprof already and it's a
> really nice tool that shows a deep stack-trace based hierarchical
> "vertical" profile instead of the usual finegrained profile.

Does it meany Linux give up implementing DTrace way of 
tracing/instrumntation ? In last time I observe more and more signs 
inroducing parallel ways of tracing/instrumentations infrasctructures in 
Linux kernel where all this can be rolled into only one .. common. Strange 
but some of this tracing/instrumentations does not uses "zero cost probes"
but "near zero cost probes" (like this) and this will result only more and 
more bloated kernel code with statically injected instrumentations.

(DTrace have very hermecic source code. In this case it mean DTrace have 
*very* limited point of entry to all other source code. In case Linux 
numbers of points of entry to instrumented code seems constantly growing 
by introducing sometimes duplicationg instrumentations infrastructures: 
oprofile, Text editor, sysprof/ftrace, utrace, blktrace .. what will be 
next ?).

Is this any explanation this (looks like completly) ad hoc/haotic Linux
way ?

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko | *e-mail: kloczek@rudy.mif.pg.gda.pl*

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-18  9:33                   ` Tomasz Kłoczko
@ 2008-04-18  9:42                     ` Ingo Molnar
  0 siblings, 0 replies; 71+ messages in thread
From: Ingo Molnar @ 2008-04-18  9:42 UTC (permalink / raw)
  To: Tomasz Kłoczko
  Cc: Andrew Morton, Christoph Hellwig, Pekka Enberg, linux-kernel,
	Linus Torvalds, Arjan van de Ven


* Tomasz Kłoczko <kloczek@rudy.mif.pg.gda.pl> wrote:

>> and you'll see the trace events go by, live. The user-space bits of 
>> sysprof have been ported over to ftrace/sysprof already and it's a 
>> really nice tool that shows a deep stack-trace based hierarchical 
>> "vertical" profile instead of the usual finegrained profile.
>
> Does it meany Linux give up implementing DTrace way of 
> tracing/instrumntation ? In last time I observe more and more signs 
> inroducing parallel ways of tracing/instrumentations infrasctructures 
> in Linux kernel where all this can be rolled into only one .. common. 

the goal of having more generic markers is still possible and being 
aimed for - for in-kernel utilization like SystemTap, lttng, utrace, 
ftrace and similar. The latest iteration of markers looks rather 
promising in terms of giving us near-zero-cost probe points.

(and last i checked dtrace was not capable of doing something like 
mmiotrace - so it's a different thing.)

so dont worry :)

	Ingo

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-18  8:38     ` Ingo Molnar
@ 2008-04-18 10:51       ` Andi Kleen
  0 siblings, 0 replies; 71+ messages in thread
From: Andi Kleen @ 2008-04-18 10:51 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Alexander van Heukelum, linux-kernel, Thomas Gleixner, H. Peter Anvin


> Andi will have to prove his points by coming up with competing benchmark 
> results - 

My point was really: "don't merge based on bogus benchmarks" or
perhaps better put: every time you see a benchmark result turn on your
brain and make sure it is really measuring something that makes sense
and also "don't put results from bogus benchmarks into change logs"

I actually don't have a big issue with the patches themselves (they
seem reasonably clean so they don't make the code worse, although I
don't think they are a significant improvement over the previous code
either), just  with the methology they were submitted.

> I dont really understand the negativism that comes from Andi - he was

I object to using bogus benchmarks.

> very much aware of the various iterations and benchmarks you did when 
> developing this rather cool feature: he participated in those threads 
> and was Cc:-ed as well. The "100% bogus benchmark with the most 

The initial "1...n" benchmark after which you merged the patch
definitely fit my "bogus" description. If there was a later better one I
had missed that indeed, sorry and I don't remember being cc'ed on one
such (except in Alexander's latest answer which satisfied me)

-Andi



^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17 10:42                     ` Pekka Enberg
@ 2008-04-18 11:12                       ` Nick Piggin
  0 siblings, 0 replies; 71+ messages in thread
From: Nick Piggin @ 2008-04-18 11:12 UTC (permalink / raw)
  To: Pekka Enberg
  Cc: Ingo Molnar, Andrew Morton, linux-kernel, Linus Torvalds,
	Thomas Gleixner, H. Peter Anvin, Vegard Nossum, Nick Piggin

On Thursday 17 April 2008 20:42, Pekka Enberg wrote:
> On Thu, Apr 17, 2008 at 1:38 PM, Ingo Molnar <mingo@elte.hu> wrote:
> >  > We (still!) have not made the decision whether to proceed with slab or
> >  > slub.  How hard would it be to port kmemcheck into slab?
> >
> >  i think slab is clearly out, unless some catastrophic regression is
> >  found. But Nick's SLQB might replace SLUB ;-)
>
> Hey, we all have our favorite replacements for kmalloc():
>
> http://www.kernel.org/pub/linux/kernel/people/penberg/patches/binalloc/2.6.
>25-rc8/kmalloc-binning
>
> But it seems unrealistic to expect any of them to replace SLUB or SLAB
> in the near future.

Obviously that one won't because it is totally unsuitable to replace
SLAB. It may be a good choice to replace SLOB (if it is found to be
technically better). Just the same as SLQB might replace SLAB if it
is found to be technically better. That's (one main criteria for) how
we merge/decide between things.

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-17 14:01                     ` Arjan van de Ven
  2008-04-17 15:26                       ` Ingo Molnar
@ 2008-04-18 12:41                       ` Ingo Molnar
  1 sibling, 0 replies; 71+ messages in thread
From: Ingo Molnar @ 2008-04-18 12:41 UTC (permalink / raw)
  To: Arjan van de Ven
  Cc: Andrew Morton, Pekka Enberg, linux-kernel, Linus Torvalds,
	Thomas Gleixner, H. Peter Anvin, Vegard Nossum


* Arjan van de Ven <arjan@infradead.org> wrote:

> > i think slab is clearly out, unless some catastrophic regression is 
> > found.
> 
> SLUB still has that several percent TPC-C regression.... Christoph has 
> a small reproducer testcase.

btw., several percent of TPC-C is bad... so i take back the 'SLAB is 
out' observation for now :-/

	Ingo

^ permalink raw reply	[flat|nested] 71+ messages in thread

* Re: [v2.6.26] what's brewing in x86.git for v2.6.26
  2008-04-18  8:18           ` David Miller
@ 2008-04-18 12:48             ` Ingo Molnar
  0 siblings, 0 replies; 71+ messages in thread
From: Ingo Molnar @ 2008-04-18 12:48 UTC (permalink / raw)
  To: David Miller; +Cc: hch, akpm, linux-kernel, arjan


* David Miller <davem@davemloft.net> wrote:

> > > include/asm/pgtable.h: In function `set_pte_at':
> > > include/asm/pgtable.h:670: warning: `init_mm' is deprecated (declared at include/linux/sched.h:1616)
> > 
> > Why is is deprecated anyway?  I think we all agreed that killing the 
> > export is good, but I don't see any way how we could kill the core 
> > useage.
> 
> set_pte_at() is done inside drivers and what-not, you're not going to 
> be able to get rid of this export so easily.

ok, good point, i zapped this change [it was in the x86/testing section 
anyway, i.e. not to be pushed upstream as an x86 change] - and if it's 
resubmitted it should be sent to -mm anyway. Arjan, what do you think?

	Ingo

^ permalink raw reply	[flat|nested] 71+ messages in thread

end of thread, other threads:[~2008-04-18 12:49 UTC | newest]

Thread overview: 71+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-04-16 20:23 [v2.6.26] what's brewing in x86.git for v2.6.26 Ingo Molnar
2008-04-16 20:37 ` Roland Dreier
2008-04-16 22:18   ` Suresh Siddha
2008-04-16 20:50 ` Andi Kleen
2008-04-17 10:06   ` Alexander van Heukelum
2008-04-17 10:51     ` Andi Kleen
2008-04-17 13:33       ` Alexander van Heukelum
2008-04-18  8:38     ` Ingo Molnar
2008-04-18 10:51       ` Andi Kleen
2008-04-17  7:25 ` Andrew Morton
2008-04-17  7:45   ` Pekka Enberg
2008-04-17  8:20     ` Andrew Morton
2008-04-17  8:32       ` Pekka J Enberg
2008-04-17  8:34         ` Pekka Enberg
2008-04-17  8:40           ` Ingo Molnar
2008-04-17  8:42           ` Andrew Morton
2008-04-17 11:49             ` Christoph Hellwig
2008-04-17 11:56               ` Ingo Molnar
2008-04-17 18:01               ` Andrew Morton
2008-04-17 18:51                 ` Ingo Molnar
2008-04-17 19:57                   ` Andrew Morton
2008-04-17 20:18                     ` Ingo Molnar
2008-04-18  9:33                   ` Tomasz Kłoczko
2008-04-18  9:42                     ` Ingo Molnar
2008-04-17  8:14   ` Andrew Morton
2008-04-17  8:57     ` Avi Kivity
2008-04-17 10:32     ` Johannes Weiner
2008-04-17 10:50       ` Andrew Morton
2008-04-17 11:49     ` Christoph Hellwig
2008-04-17 17:36       ` Andrew Morton
2008-04-17  8:30   ` Ingo Molnar
2008-04-17  8:40     ` Andrew Morton
2008-04-17  8:45       ` David Miller
2008-04-17  8:54         ` Andrew Morton
2008-04-17  8:56           ` Andrew Morton
2008-04-17  9:19           ` David Miller
2008-04-17  9:33             ` Andrew Morton
2008-04-17  9:06       ` Ingo Molnar
2008-04-17  9:18         ` Andrew Morton
2008-04-17  9:30           ` Ingo Molnar
2008-04-17  9:36             ` Andrew Morton
2008-04-17  9:46               ` Ingo Molnar
2008-04-17 10:06                 ` Andrew Morton
2008-04-17 10:11               ` Andi Kleen
2008-04-17 10:18                 ` Andrew Morton
2008-04-17 10:29                   ` Andi Kleen
2008-04-17 10:19               ` Pekka Enberg
2008-04-17 10:33                 ` Andrew Morton
2008-04-17 10:38                   ` Ingo Molnar
2008-04-17 10:42                     ` Pekka Enberg
2008-04-18 11:12                       ` Nick Piggin
2008-04-17 14:01                     ` Arjan van de Ven
2008-04-17 15:26                       ` Ingo Molnar
2008-04-18 12:41                       ` Ingo Molnar
2008-04-17 10:41                   ` Pekka Enberg
2008-04-17 18:47               ` Vegard Nossum
2008-04-17 19:27                 ` Ingo Molnar
2008-04-17 19:35                   ` Ingo Molnar
2008-04-17 19:39                     ` Vegard Nossum
2008-04-17 19:43                 ` Andrew Morton
2008-04-17 20:39                   ` Vegard Nossum
2008-04-17 20:55                     ` Andrew Morton
2008-04-17  9:53             ` Andrew Morton
2008-04-17  7:48 ` Andrew Morton
2008-04-18  6:27 ` Andrew Morton
2008-04-18  6:38   ` David Miller
2008-04-18  7:47     ` Ingo Molnar
2008-04-18  8:00       ` Andrew Morton
2008-04-18  8:11         ` Christoph Hellwig
2008-04-18  8:18           ` David Miller
2008-04-18 12:48             ` Ingo Molnar

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).