1. 15 10月, 2008 1 次提交
  2. 21 9月, 2008 1 次提交
  3. 29 1月, 2008 1 次提交
  4. 30 10月, 2007 1 次提交
  5. 17 10月, 2007 3 次提交
  6. 12 10月, 2007 1 次提交
  7. 01 10月, 2007 1 次提交
  8. 27 8月, 2007 1 次提交
  9. 20 7月, 2007 1 次提交
    • F
      define new percpu interface for shared data · 5fb7dc37
      Fenghua Yu 提交于
      per cpu data section contains two types of data.  One set which is
      exclusively accessed by the local cpu and the other set which is per cpu,
      but also shared by remote cpus.  In the current kernel, these two sets are
      not clearely separated out.  This can potentially cause the same data
      cacheline shared between the two sets of data, which will result in
      unnecessary bouncing of the cacheline between cpus.
      
      One way to fix the problem is to cacheline align the remotely accessed per
      cpu data, both at the beginning and at the end.  Because of the padding at
      both ends, this will likely cause some memory wastage and also the
      interface to achieve this is not clean.
      
      This patch:
      
      Moves the remotely accessed per cpu data (which is currently marked
      as ____cacheline_aligned_in_smp) into a different section, where all the data
      elements are cacheline aligned. And as such, this differentiates the local
      only data and remotely accessed data cleanly.
      Signed-off-by: NFenghua Yu <fenghua.yu@intel.com>
      Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Christoph Lameter <clameter@sgi.com>
      Cc: <linux-arch@vger.kernel.org>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5fb7dc37
  10. 19 5月, 2007 2 次提交
  11. 03 5月, 2007 1 次提交
  12. 12 2月, 2007 1 次提交
  13. 12 12月, 2006 1 次提交
    • R
      [MIPS] Discard .exit.text and .exit.data at runtime. · 2efac77e
      Ralf Baechle 提交于
      While the recent cset 86384d54 did improve
      things it didn't resolve all the problems.  So bite the bullet and discard
      .exit.text and .exit.data at runtime.  Which of course sucks because it
      bloats binaries with code that will never ever be used but it's the only
      thing that will work reliable as demonstrated by the function sd_major() in
      drivers/scsi/sd.c.
      
      Gcc may compile sd_major() using a jump table which it will put into
      .rodata.  If it also inlines sd_major's function body into exit_sd() which
      gcc > 3.4.x does.  If CONFIG_BLK_DEV_SD has been set to y we would like ld
      to discard exit_sd's code at link time.  However sd_major happens to
      contain a switch statement which gcc will compile using a jump table in
      .rodata on the architectures I checked.  So, when ld later discards
      .exit.text only the jump table in .rodata with its stale references to
      the discard .exit.text will be left which any no antique ld will honor
      with a link error.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      2efac77e
  14. 11 12月, 2006 1 次提交
  15. 02 11月, 2006 1 次提交
  16. 28 10月, 2006 1 次提交
  17. 01 7月, 2006 1 次提交
  18. 01 6月, 2006 2 次提交
  19. 19 4月, 2006 1 次提交
  20. 10 3月, 2006 1 次提交
    • R
      [MIPS] Discard .exit.text at runtime. · bb7d83f7
      Ralf Baechle 提交于
          
      At times gcc will place bits of __exit functions into .rodata.  If
      compiled into the kernle itself we used to discard .exit.text - but
      not the bits left in .rodata.  While harmless this did at times result
      in a large number of warnings.  So until gcc fixes this, discard
      .exit.text at runtime.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      bb7d83f7
  21. 07 2月, 2006 1 次提交
  22. 30 10月, 2005 2 次提交
  23. 05 9月, 2005 1 次提交
  24. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4