1. 09 Oct, 2014 1 commit
  2. 03 Jul, 2013 1 commit
    • Jiang Liu's avatar
      vmlinux.lds: add comments for global variables and clean up useless declarations · 1622d1ab
      Jiang Liu authored
      The original goal of this patchset is to fix the bug reported by
      https://bugzilla.kernel.org/show_bug.cgi?id=53501 Now it has also been
      expanded to reduce common code used by memory initializion.
      Patch 1-7:
      	1) add comments for global variables exported by vmlinux.lds
      	2) normalize global variables exported by vmlinux.lds
      Patch 8:
      	Introduce helper functions mem_init_print_info() and
      Patch 9:
      	Avoid using global variable num_physpages at runtime
      Patch 10:
      	Don't update num_physpages in memory_hotplug.c
      Patch 11-40:
      	Modify arch mm initialization code to:
      	1) Simplify mem_init() by using mem_init_print_info()
      	2) Prepare for killing global variable num_physpages
      Patch 41:
      	Kill the global variable num_physpages
      With all patches applied, mem_init(), free_initmem(), free_initrd_mem()
      could be as simple as below.  This patch series has reduced about 1.2K
      lines of code in total.
      void __init
      	max_mapnr = max_low_pfn;
      	high_memory = (void *) __va(max_low_pfn * PAGE_SIZE);
      #endif /* CONFIG_DISCONTIGMEM */
      free_initrd_mem(unsigned long start, unsigned long end)
      	free_reserved_area(start, end, -1, "initrd");
      Due to hardware resource limitations, I have only tested this on x86_64.
      And the messages reported on an x86_64 system are:
      Log message before applying patches:
      Memory: 7745676k/8910848k available (6934k kernel code, 836024k absent, 329148k reserved, 6343k data, 1012k init)
      Log message after applying patches:
      Memory: 7744624K/8074824K available (6969K kernel code, 1011K data, 2828K rodata, 1016K init, 9640K bss, 330200K reserved)
      Great thanks to Vineet Gupta for testing on ARC.
      This patch:
      Document global variables exported from vmlinux.lds.
      1) Add comments about usage guidelines for global variables exported
         from vmlinux.lds.S.
      2) Remove unused __initdata_begin[] and __initdata_end[].
      Signed-off-by: default avatarJiang Liu <jiang.liu@huawei.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  3. 08 Mar, 2011 1 commit
    • Jiri Olsa's avatar
      x86: Separate out entry text section · ea714547
      Jiri Olsa authored
      Put x86 entry code into a separate link section: .entry.text.
      Separating the entry text section seems to have performance
      benefits - caused by more efficient instruction cache usage.
      Running hackbench with perf stat --repeat showed that the change
      compresses the icache footprint. The icache load miss rate went
      down by about 15%:
       before patch:
               19417627  L1-icache-load-misses      ( +-   0.147% )
       after patch:
               16490788  L1-icache-load-misses      ( +-   0.180% )
      The motivation of the patch was to fix a particular kprobes
      bug that relates to the entry text section, the performance
      advantage was discovered accidentally.
      Whole perf output follows:
       - results for current tip tree:
        Performance counter stats for './hackbench/hackbench 10' (500 runs):
               19417627  L1-icache-load-misses      ( +-   0.147% )
             2676914223  instructions             #      0.497 IPC     ( +- 0.079% )
             5389516026  cycles                     ( +-   0.144% )
            0.206267711  seconds time elapsed   ( +-   0.138% )
       - results for current tip tree with the patch applied:
        Performance counter stats for './hackbench/hackbench 10' (500 runs):
               16490788  L1-icache-load-misses      ( +-   0.180% )
             2717734941  instructions             #      0.502 IPC     ( +- 0.079% )
             5414756975  cycles                     ( +-   0.148% )
            0.206747566  seconds time elapsed   ( +-   0.137% )
      Signed-off-by: default avatarJiri Olsa <jolsa@redhat.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Nick Piggin <npiggin@kernel.dk>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: masami.hiramatsu.pt@hitachi.com
      Cc: ananth@in.ibm.com
      Cc: davem@davemloft.net
      Cc: 2nddept-manager@sdl.hitachi.co.jp
      LKML-Reference: <20110307181039.GB15197@jolsa.redhat.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  4. 23 Sep, 2009 1 commit
  5. 18 Jun, 2009 1 commit
  6. 16 Jan, 2009 1 commit
    • Tejun Heo's avatar
      x86: make percpu symbols zerobased on SMP · 3e5d8f97
      Tejun Heo authored
      [ Based on original patch from Christoph Lameter and Mike Travis. ]
      This patch makes percpu symbols zerobased on x86_64 SMP by adding
      PERCPU_VADDR() to vmlinux.lds.h which helps setting explicit vaddr on
      the percpu output section and using it in vmlinux_64.lds.S.  A new
      PHDR is added as existing ones cannot contain sections near address
      zero.  PERCPU_VADDR() also adds a new symbol __per_cpu_load which
      always points to the vaddr of the loaded percpu data.init region.
      The following adjustments have been made to accomodate the address
      * code to locate percpu gdt_page in head_64.S is updated to add the
        load address to the gdt_page offset.
      * __per_cpu_load is used in places where access to the init data area
        is necessary.
      * pda->data_offset is initialized soon after C code is entered as zero
        value doesn't work anymore.
      This patch is mostly taken from Mike Travis' "x86_64: Base percpu
      variables at zero" patch.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  7. 09 Sep, 2008 1 commit
  8. 06 Feb, 2008 1 commit
  9. 01 Jul, 2006 1 commit
  10. 14 Nov, 2005 1 commit
  11. 07 Sep, 2005 1 commit
    • Prasanna S Panchamukhi's avatar
      [PATCH] Kprobes: prevent possible race conditions generic · d0aaff97
      Prasanna S Panchamukhi authored
      There are possible race conditions if probes are placed on routines within the
      kprobes files and routines used by the kprobes.  For example if you put probe
      on get_kprobe() routines, the system can hang while inserting probes on any
      routine such as do_fork().  Because while inserting probes on do_fork(),
      register_kprobes() routine grabs the kprobes spin lock and executes
      get_kprobe() routine and to handle probe of get_kprobe(), kprobes_handler()
      gets executed and tries to grab kprobes spin lock, and spins forever.  This
      patch avoids such possible race conditions by preventing probes on routines
      within the kprobes file and routines used by kprobes.
      I have modified the patches as per Andi Kleen's suggestion to move kprobes
      routines and other routines used by kprobes to a seperate section
      Also moved page fault and exception handlers, general protection fault to
      .kprobes.text section.
      These patches have been tested on i386, x86_64 and ppc64 architectures, also
      compiled on ia64 and sparc64 architectures.
      Signed-off-by: default avatarPrasanna S Panchamukhi <prasanna@in.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  12. 28 Jul, 2005 1 commit
  13. 05 May, 2005 1 commit
  14. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      Let it rip!