1. 29 Sep, 2002 8 commits
    • Ingo Molnar's avatar
      [PATCH] smptimers, old BH removal, tq-cleanup · dd140c87
      Ingo Molnar authored
      This is the smptimers patch plus the removal of old BHs and a rewrite of
      task-queue handling.
      
      Basically with the removal of TIMER_BH i think the time is right to get
      rid of old BHs forever, and to do a massive cleanup of all related
      fields.  The following five basic 'execution context' abstractions are
      supported by the kernel:
      
        - hardirq
        - softirq
        - tasklet
        - keventd-driven task-queues
        - process contexts
      
      I've done the following cleanups/simplifications to task-queues:
      
       - removed the ability to define your own task-queue, what can be done is
         to schedule_task() a given task to keventd, and to flush all pending
         tasks.
      
      This is actually a quite easy transition, since 90% of all task-queue
      users in the kernel used BH_IMMEDIATE - which is very similar in
      functionality to keventd.
      
      I believe task-queues should not be removed from the kernel altogether.
      It's true that they were written as a candidate replacement for BHs
      originally, but they do make sense in a different way: it's perhaps the
      easiest interface to do deferred processing from IRQ context, in
      performance-uncritical code areas.  They are easier to use than
      tasklets.
      
      code that cares about performance should convert to tasklets - as the
      timer code and the serial subsystem has done already. For extreme
      performance softirqs should be used - the net subsystem does this.
      
      and we can do this for 2.6 - there are only a couple of areas left after
      fixing all the BH_IMMEDIATE places.
      
      i have moved all the taskqueue handling code into kernel/context.c, and
      only kept the basic 'queue a task' definitions in include/linux/tqueue.h.
      I've converted three of the most commonly used BH_IMMEDIATE users:
      tty_io.c, floppy.c and random.c. [random.c might need more thought
      though.]
      
      i've also cleaned up kernel/timer.c over that of the stock smptimers
      patch: privatized the timer-vec definitions (nothing needs it,
      init_timer() used it mistakenly) and cleaned up the code. Plus i've moved
      some code around that does not belong into timer.c, and within timer.c
      i've organized data and functions along functionality and further
      separated the base timer code from the NTP bits.
      
      net_bh_lock: i have removed it, since it would synchronize to nothing. The
      old protocol handlers should still run on UP, and on SMP the kernel prints
      a warning upon use. Alexey, is this approach fine with you?
      
      scalable timers: i've further improved the patch ported to 2.5 by wli and
      Dipankar. There is only one pending issue i can see, the question of
      whether to migrate timers in mod_timer() or not. I'm quite convinced that
      they should be migrated, but i might be wrong. It's a 10 lines change to
      switch between migrating and non-migrating timers, we can do performance
      tests later on. The current, more complex migration code is pretty fast
      and has been stable under extremely high networking loads in the past 2
      years, so we can immediately switch to the simpler variant if someone
      proves it improves performance. (I'd say if non-migrating timers improve
      Apache performance on one of the bigger NUMA boxes then the point is
      proven, no further though will be needed.)
      dd140c87
    • Ingo Molnar's avatar
      [PATCH] atomic-thread-signals · 5a5ec729
      Ingo Molnar authored
      Avoid racing on signal delivery with thread signal blocking in thread
      groups.
      
      The method to do this is to eliminate the per-thread sigmask_lock, and
      use the per-group (per 'process') siglock for all signal related
      activities.  This immensely simplified some of the locking interactions
      within signal.c, and enabled the fixing of the above category of signal
      delivery races.
      
      This became possible due to the former thread-signal patch, which made
      siglock an irq-safe thing.  (it used to be a process-context-only
      spinlock.) And this is even a speedup for non-threaded applications:
      only one lock is used.
      
      I fixed all places within the kernel except the non-x86 arch sections.
      Even for them the transition is very straightforward, in almost every
      case the following is sufficient in arch/*/kernel/signal.c:
      
      		:1,$s/->sigmask_lock/->sig->siglock/g
      5a5ec729
    • Ingo Molnar's avatar
      [PATCH] thread-group SIGSTOP handling · 5360ccf4
      Ingo Molnar authored
      Fix thread-group SIGSTOP handling - the SIGSTOP notification was not
      propagated to the parent of the thread group leader.  Now Ctrl-Z-ing of
      thread groups works again.
      5360ccf4
    • Ingo Molnar's avatar
      [PATCH] signal delivery to thread groups bugfix · 8c739876
      Ingo Molnar authored
      Fix thread group signal sending
      8c739876
    • Ingo Molnar's avatar
      [PATCH] futex-fix-2.5.39-A1 · aa016b08
      Ingo Molnar authored
      This fixes one more race left in the new futex hashing code, which
      triggers if a futex waiter gets a signal after it has been woken up but
      before it actually wakes up.
      aa016b08
    • Ingo Molnar's avatar
      [PATCH] sigfix-2.5.39-A1 · 6e21ad7b
      Ingo Molnar authored
      This fixes the bug reported by David Mosberger, force_sig_info() dropped
      the siginfo structure, which broke things like SIGFPU or alignment-error
      exceptions.  This bug was introduced by the threading signal changes.
      (The patch also fixes signal declaration whitespaces in sched.h.)
      6e21ad7b
    • Jeff Garzik's avatar
    • Jeff Garzik's avatar
  2. 28 Sep, 2002 17 commits
  3. 27 Sep, 2002 15 commits