1. 07 11月, 2005 2 次提交
  2. 31 10月, 2005 1 次提交
  3. 13 9月, 2005 1 次提交
  4. 26 6月, 2005 1 次提交
    • I
      [PATCH] sched: voluntary kernel preemption · f8cbd99b
      Ingo Molnar 提交于
      This patch adds a new preemption model: 'Voluntary Kernel Preemption'.  The
      3 models can be selected from a new menu:
      
                  (X) No Forced Preemption (Server)
                  ( ) Voluntary Kernel Preemption (Desktop)
                  ( ) Preemptible Kernel (Low-Latency Desktop)
      
      we still default to the stock (Server) preemption model.
      
      Voluntary preemption works by adding a cond_resched()
      (reschedule-if-needed) call to every might_sleep() check.  It is lighter
      than CONFIG_PREEMPT - at the cost of not having as tight latencies.  It
      represents a different latency/complexity/overhead tradeoff.
      
      It has no runtime impact at all if disabled.  Here are size stats that show
      how the various preemption models impact the kernel's size:
      
          text    data     bss     dec     hex filename
       3618774  547184  179896 4345854  424ffe vmlinux.stock
       3626406  547184  179896 4353486  426dce vmlinux.voluntary   +0.2%
       3748414  548640  179896 4476950  445016 vmlinux.preempt     +3.5%
      
      voluntary-preempt is +0.2% of .text, preempt is +3.5%.
      
      This feature has been tested for many months by lots of people (and it's
      also included in the RHEL4 distribution and earlier variants were in Fedora
      as well), and it's intended for users and distributions who dont want to
      use full-blown CONFIG_PREEMPT for one reason or another.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f8cbd99b
  5. 01 5月, 2005 1 次提交
  6. 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