26 Jun, 2005

3 commits

  • 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: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ingo Molnar
     
  • The only sane way to clean up the current 3 lock_kernel() variants seems to
    be to remove the spinlock-based BKL implementations altogether, and to keep
    the semaphore-based one only. If we dont want to do that for whatever
    reason then i'm afraid we have to live with the current complexity. (but
    i'm open for other cleanup suggestions as well.)

    To explore this possibility we'll (at a minimum) have to know whether the
    semaphore-based BKL works fine on plain SMP too. The patch below enables
    this.

    The patch may make sense in isolation as well, as it might bring
    performance benefits: code that would formerly spin on the BKL spinlock
    will now schedule away and give up the CPU. It might introduce performance
    regressions as well, if any performance-critical code uses the BKL heavily
    and gets overscheduled due to the semaphore. I very much hope there is no
    such performance-critical codepath left though.

    Signed-off-by: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ingo Molnar
     
  • This patch consolidates the CONFIG_PREEMPT and CONFIG_PREEMPT_BKL
    preemption options into kernel/Kconfig.preempt. This, besides reducing
    source-code, also enables more centralized tweaking of preemption related
    options.

    Signed-off-by: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ingo Molnar