1. 09 1月, 2006 3 次提交
    • M
      [PATCH] tiny: Make *[ug]id16 support optional · e585e470
      Matt Mackall 提交于
      Configurable 16-bit UID and friends support
      
      This allows turning off the legacy 16 bit UID interfaces on embedded platforms.
      
         text    data     bss     dec     hex filename
      3330172  529036  190556 4049764  3dcb64 vmlinux-baseline
      3328268  529040  190556 4047864  3dc3f8 vmlinux
      
      From: Adrian Bunk <bunk@stusta.de>
      
          UID16 was accidentially disabled for !EMBEDDED.
      Signed-off-by: NMatt Mackall <mpm@selenic.com>
      Signed-off-by: NAdrian Bunk <bunk@stusta.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e585e470
    • M
      [PATCH] tiny: Make x86 doublefault handling optional · 22c4e308
      Matt Mackall 提交于
      This adds configurable support for doublefault reporting on x86
      
      add/remove: 0/3 grow/shrink: 0/1 up/down: 0/-13048 (-13048)
      function                                     old     new   delta
      cpu_init                                     846     786     -60
      doublefault_fn                               188       -    -188
      doublefault_stack                           4096       -   -4096
      doublefault_tss                             8704       -   -8704
      Signed-off-by: NMatt Mackall <mpm@selenic.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      22c4e308
    • M
      [PATCH] slob: introduce the SLOB allocator · 10cef602
      Matt Mackall 提交于
      configurable replacement for slab allocator
      
      This adds a CONFIG_SLAB option under CONFIG_EMBEDDED.  When CONFIG_SLAB is
      disabled, the kernel falls back to using the 'SLOB' allocator.
      
      SLOB is a traditional K&R/UNIX allocator with a SLAB emulation layer,
      similar to the original Linux kmalloc allocator that SLAB replaced.  It's
      signicantly smaller code and is more memory efficient.  But like all
      similar allocators, it scales poorly and suffers from fragmentation more
      than SLAB, so it's only appropriate for small systems.
      
      It's been tested extensively in the Linux-tiny tree.  I've also
      stress-tested it with make -j 8 compiles on a 3G SMP+PREEMPT box (not
      recommended).
      
      Here's a comparison for otherwise identical builds, showing SLOB saving
      nearly half a megabyte of RAM:
      
      $ size vmlinux*
         text    data     bss     dec     hex filename
      3336372  529360  190812 4056544  3de5e0 vmlinux-slab
      3323208  527948  190684 4041840  3dac70 vmlinux-slob
      
      $ size mm/{slab,slob}.o
         text    data     bss     dec     hex filename
        13221     752      48   14021    36c5 mm/slab.o
         1896      52       8    1956     7a4 mm/slob.o
      
      /proc/meminfo:
                        SLAB          SLOB      delta
      MemTotal:        27964 kB      27980 kB     +16 kB
      MemFree:         24596 kB      25092 kB    +496 kB
      Buffers:            36 kB         36 kB       0 kB
      Cached:           1188 kB       1188 kB       0 kB
      SwapCached:          0 kB          0 kB       0 kB
      Active:            608 kB        600 kB      -8 kB
      Inactive:          808 kB        812 kB      +4 kB
      HighTotal:           0 kB          0 kB       0 kB
      HighFree:            0 kB          0 kB       0 kB
      LowTotal:        27964 kB      27980 kB     +16 kB
      LowFree:         24596 kB      25092 kB    +496 kB
      SwapTotal:           0 kB          0 kB       0 kB
      SwapFree:            0 kB          0 kB       0 kB
      Dirty:               4 kB         12 kB      +8 kB
      Writeback:           0 kB          0 kB       0 kB
      Mapped:            560 kB        556 kB      -4 kB
      Slab:             1756 kB          0 kB   -1756 kB
      CommitLimit:     13980 kB      13988 kB      +8 kB
      Committed_AS:     4208 kB       4208 kB       0 kB
      PageTables:         28 kB         28 kB       0 kB
      VmallocTotal:  1007312 kB    1007312 kB       0 kB
      VmallocUsed:        48 kB         48 kB       0 kB
      VmallocChunk:  1007264 kB    1007264 kB       0 kB
      
      (this work has been sponsored in part by CELF)
      
      From: Ingo Molnar <mingo@elte.hu>
      
         Fix 32-bitness bugs in mm/slob.c.
      Signed-off-by: NMatt Mackall <mpm@selenic.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      10cef602
  2. 07 1月, 2006 2 次提交
  3. 05 1月, 2006 2 次提交
  4. 27 12月, 2005 1 次提交
  5. 21 12月, 2005 1 次提交
  6. 15 12月, 2005 1 次提交
    • L
      Move size optimization option outside of EMBEDDED menu, mark it EXPERIMENTAL · c45b4f1f
      Linus Torvalds 提交于
      Also, disable on sparc64 - a number of people report breakage.  Probably
      a compiler bug, but it's quite possible that it tickles some latent
      kernel problem too.
      
      It still defaults to 'y' everywhere else (when enabled through
      EXPERIMENTAL), and Dave Jones points out that Fedora (and RHEL4) has
      been building with size optimizations for a long time on x86, x86-64,
      ia64, s390, s390x, ppc32 and ppc64.  So it is really only moderately
      experimental, but the sparc64 breakage certainly shows that it can
      trigger "issues".
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c45b4f1f
  7. 14 12月, 2005 2 次提交
  8. 04 11月, 2005 1 次提交
  9. 31 10月, 2005 1 次提交
  10. 11 8月, 2005 2 次提交
  11. 28 7月, 2005 1 次提交
  12. 26 7月, 2005 1 次提交
  13. 11 7月, 2005 1 次提交
  14. 29 5月, 2005 1 次提交
  15. 11 5月, 2005 1 次提交
  16. 08 5月, 2005 1 次提交
  17. 03 5月, 2005 1 次提交
  18. 01 5月, 2005 2 次提交
  19. 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