[lkml]   [2001]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] softirq performance fixes, cleanups, 2.4.10.

On Fri, 28 Sep 2001, Oleg Nesterov wrote:

> I am trying to understand the basics of softirq handling.
> It seems to me that ksoftirqd()'s loop can be cleanuped a bit with
> following (untested) patch on top of 2.4.10-softirq-A7.

thanks - the patch looks mostly correct.

> It also removes the 'mask' variable in do_softirq().

(right, applied.)

> - schedule();
> - __set_current_state(TASK_INTERRUPTIBLE);

we need a single schedule to migrate the CPU to the right CPU. Btw, it's
not a big offense to run on the wrong CPU: do_softirq() will run
correctly. But there wont be a ksoftirqd exeuting on the 'right' CPU (for
this short amount of time until it schedules once), and we might miss a
single instance of softirq processing. So it's cleaner to do a schedule()
that guarantees that we migrate to the target CPU.

> + __set_current_state(TASK_RUNNING);
> + }

well, this basically reverts it to the original code and removes the
optimization - but i dont have any strong feelings in either way. I think
Andrea is right and it's more correct to set it TASK_RUNNING, for
task-statistics reasons. Reverted it to the old code.

and in fact while doing that i found another bug in the old code:
TASK_INTERRUPTIBLE was set in a non-IRQ-atomic way, so theoretically it
could be possible that the compiler reorders the setting of
TASK_INTERRUPTIBLE and the test for softirq_pending(), and if an IRQ gets
inbetween the we could miss processing softirq for 1/HZ again. Added an
optimization barrier(). (SMP-consistency is not needed, since we are


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:17    [W:0.079 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site