question about softirqs

I'm trying to figure out where exactly softirqs are called on return from a syscall in 64-bit powerpc. I can see where they get called for a normal interrupt via the irq_exit() path, but not for syscalls.

I'm sure I'm missing something obvious...can anyone help?

I'm trying to figure out where exactly softirqs are called on return from a syscall in 64-bit powerpc. I can see where they get called for a normal interrupt via the irq_exit() path, but not for syscalls.

If a soft irq is raised in process context, raise_softirq() in kernel/softirq.c calls wakeup_softirqd() to make sure that ksoftirqd runs soon to process the soft irq. So what would happen is that we would see the TIF_RESCHED_PENDING flag on the current task in the syscall exit path and call schedule() which would switch to ksoftirqd to process the soft irq (if it hasn't already been processed by that stage).

If the soft irq is raised in interrupt context, then the soft irq gets run via the do_softirq() call in irq_exit(), as you saw.

The soft irq stuff is pretty much all generic code these days, except for the code to switch to the softirq stack.

If a soft irq is raised in process context, raise_softirq() in kernel/softirq.c calls wakeup_softirqd() to make sure that ksoftirqd runs soon to process the soft irq. So what would happen is that we would see the TIF_RESCHED_PENDING flag on the current task in the syscall exit path and call schedule() which would switch to ksoftirqd to process the soft irq (if it hasn't already been processed by that stage).

Quoted 3 lines

The soft irq stuff is pretty much all generic code these days, except for the code to switch to the softirq stack.

Grumble, when did that happen :-(

That's horrible for latency compared to handling it directly in the trap return path.

Grumble, when did that happen :-(

That's horrible for latency compared to handling it directly in the trap return path.

Quoted 1 line · David Miller

Grumble, when did that happen :-(

Ages ago (i.e. before the switch to git :). Talk to Ingo, it's his doing IIRC.

Quoted 2 lines

That's horrible for latency compared to handling it directly in the trap return path.

Actually, I don't know why we ever let there be softirqs pending when we're in process context. I would think that we should just call do_softirq immediately if we raise a softirq when !in_interrupt(). But I might be missing some subtlety.

You know, for networking over loopback (one of the only real cases that even matters, if we get a hard interrupt then the return from that would process any softints), we probably make out just fine anyways. As long as we hit a local_bh_enable() (and in the return path from device transmit that's exceedingly likely as all of the networking locking is BH safe) we'll run the softints from that and thus long before we get to syscall return.

Quoted 7 lines · David Miller

You know, for networking over loopback (one of the only real cases that even matters, if we get a hard interrupt then the return from that would process any softints), we probably make out just fine anyways. As long as we hit a local_bh_enable() (and in the return path from device transmit that's exceedingly likely as all of the networking locking is BH safe) we'll run the softints from that and thus long before we get to syscall return.

What about the issue I raised earlier? (I don't think you were copied at that point.)

Suppose I have a SCHED_FIFO task spinning on recvmsg() with MSG_DONTWAIT set (and maybe doing other stuff if there are no messages). In this case, schedule() would re-run the spinning task rather than running ksoftirqd. This could prevent any incoming packets from actually being sent up the stack until we get a real hardware interrupt--which could be a whole jiffy if interrupt mitigation is enabled in the net device.

(And maybe longer if NOHZ is enabled.)

This started out as a thread on the ppc list, but on the suggestion of DaveM and Paul Mackerras I'm expanding the receiver list a bit.

Currently, if a softirq is raised in process context the TIF_RESCHED_PENDING flag gets set and on return to userspace we run the scheduler, expecting it to switch to ksoftirqd to handle the softirqd processing.

I think I see a possible problem with this. Suppose I have a SCHED_FIFO task spinning on recvmsg() with MSG_DONTWAIT set. Under the scenario above, schedule() would re-run the spinning task rather than ksoftirqd, thus preventing any incoming packets from being sent up the stack until we get a real hardware interrupt--which could be a whole jiffy if interrupt mitigation is enabled in the net device.

DaveM pointed out that if we're doing transmits we're likely to hit local_bh_enable(), which would process the softirq work. However, I think we may still have a problem in the above rx-only scenario--or is it too contrived to matter?

Quoted 9 lines · Chris Friesen

This started out as a thread on the ppc list, but on the suggestion of DaveM and Paul Mackerras I'm expanding the receiver list a bit.

Currently, if a softirq is raised in process context the TIF_RESCHED_PENDING flag gets set and on return to userspace we run the scheduler, expecting it to switch to ksoftirqd to handle the softirqd processing.

Quoted 7 lines

I think I see a possible problem with this. Suppose I have a SCHED_FIFO task spinning on recvmsg() with MSG_DONTWAIT set. Under the scenario above, schedule() would re-run the spinning task rather than ksoftirqd, thus preventing any incoming packets from being sent up the stack until we get a real hardware interrupt--which could be a whole jiffy if interrupt mitigation is enabled in the net device.

TIF_RESCHED_PENDING will not be set if a SCHED_FIFO task wakes up a SCHED_OTHER ksoftirqd task. But starvation of ksoftirqd processing will occur.

Quoted 4 lines

DaveM pointed out that if we're doing transmits we're likely to hit local_bh_enable(), which would process the softirq work. However, I think we may still have a problem in the above rx-only scenario--or is it too contrived to matter?

This could occur, and the problem is really that task priorities do not extend across softirq work processing.

This could occur in ordinary SCHED_OTHER tasks as well, if the softirq is bounced to ksoftirqd - which it only should be if there's serious softirq overload - or, as you describe it above, if the softirq is raised in process context:

        if (!in_interrupt())
                wakeup_softirqd();

that's not really clean. We look into eliminating process context use of raise_softirq_irqsoff(). Such code sequence:

	local_irq_save(flags);
	...
	raise_softirq_irqsoff(nr);
	...
	local_irq_restore(flags);

should be converted to something like:

	local_irq_save(flags);
	...
	raise_softirq_irqsoff(nr);
	...
	local_irq_restore(flags);
	recheck_softirqs();

If someone does not do proper local_bh_disable()/enable() sequences for micro-optimization reasons, then push the check to after the critcal section - and dont cause extra reschedules by waking up ksoftirqd. raise_softirq_irqsoff() will also be faster.

Quoted 57 lines · Ingo Molnar

Quoted 9 lines · Chris Friesen

This started out as a thread on the ppc list, but on the suggestion of DaveM and Paul Mackerras I'm expanding the receiver list a bit.

Currently, if a softirq is raised in process context the TIF_RESCHED_PENDING flag gets set and on return to userspace we run the scheduler, expecting it to switch to ksoftirqd to handle the softirqd processing.

Quoted 7 lines

I think I see a possible problem with this. Suppose I have a SCHED_FIFO task spinning on recvmsg() with MSG_DONTWAIT set. Under the scenario above, schedule() would re-run the spinning task rather than ksoftirqd, thus preventing any incoming packets from being sent up the stack until we get a real hardware interrupt--which could be a whole jiffy if interrupt mitigation is enabled in the net device.

TIF_RESCHED_PENDING will not be set if a SCHED_FIFO task wakes up a SCHED_OTHER ksoftirqd task. But starvation of ksoftirqd processing will occur.

Quoted 4 lines

DaveM pointed out that if we're doing transmits we're likely to hit local_bh_enable(), which would process the softirq work. However, I think we may still have a problem in the above rx-only scenario--or is it too contrived to matter?

This could occur, and the problem is really that task priorities do not extend across softirq work processing.

This could occur in ordinary SCHED_OTHER tasks as well, if the softirq is bounced to ksoftirqd - which it only should be if there's serious softirq overload - or, as you describe it above, if the softirq is raised in process context:

        if (!in_interrupt())
                wakeup_softirqd();

that's not really clean. We look into eliminating process context use of raise_softirq_irqsoff(). Such code sequence:

	local_irq_save(flags);
	...
	raise_softirq_irqsoff(nr);
	...
	local_irq_restore(flags);

should be converted to something like:

	local_irq_save(flags);
	...
	raise_softirq_irqsoff(nr);
	...
	local_irq_restore(flags);
	recheck_softirqs();

Quoted 4 lines

If someone does not do proper local_bh_disable()/enable() sequences for micro-optimization reasons, then push the check to after the critcal section - and dont cause extra reschedules by waking up ksoftirqd. raise_softirq_irqsoff() will also be faster.

Wouldn't the even better solution be to get rid of softirqs all-together?

I see the recent work by Thomas to get threaded interrupts upstream as a good first step towards that goal, once the RX processing is moved to a thread (or multiple threads) one can priorize them in the regular sys_sched_setscheduler() way and its obvious that a FIFO task above the priority of the network tasks will have network starvation issues.

Yeah, that would be "nice". A single IRQ thread plus the process context(s) doing networking might perform well.

Multiple IRQ threads (softirq and hardirq threads mixed) i'm not so sure about - it's extra context-switching cost.

Quoted 6 lines · Ingo Molnar

Yeah, that would be "nice". A single IRQ thread plus the process context(s) doing networking might perform well.

Multiple IRQ threads (softirq and hardirq threads mixed) i'm not so sure about - it's extra context-switching cost.

Sure, that was implied by the getting rid of softirqs ;-), on -rt we currently suffer this hardirq/softirq thread ping-pong, it sucks.

Quoted 8 lines · Chris Friesen

I think I see a possible problem with this. Suppose I have a SCHED_FIFO task spinning on recvmsg() with MSG_DONTWAIT set. Under the scenario above, schedule() would re-run the spinning task rather than ksoftirqd, thus preventing any incoming packets from being sent up the stack until we get a real hardware interrupt--which could be a whole jiffy if interrupt mitigation is enabled in the net device.

Quoted 4 lines

DaveM pointed out that if we're doing transmits we're likely to hit local_bh_enable(), which would process the softirq work. However, I think we may still have a problem in the above rx-only scenario--or is it too contrived to matter?

This could occur, and the problem is really that task priorities do not extend across softirq work processing.

This could occur in ordinary SCHED_OTHER tasks as well, if the softirq is bounced to ksoftirqd - which it only should be if there's serious softirq overload - or, as you describe it above, if the softirq is raised in process context:

Quoted 9 lines

Wouldn't the even better solution be to get rid of softirqs all-together?

I see the recent work by Thomas to get threaded interrupts upstream as a good first step towards that goal, once the RX processing is moved to a thread (or multiple threads) one can priorize them in the regular sys_sched_setscheduler() way and its obvious that a FIFO task above the priority of the network tasks will have network starvation issues.

Yeah, that would be "nice". A single IRQ thread plus the process context(s) doing networking might perform well.

I'm going to be playing around with bypassing the net-rx/tx with my network drivers. I'm going to add threaded irqs for my network cards and have the driver threads do the work to get through the tcp/ip stack.

I'll still keep the softirqs for other cards, but I want to see how fast it speeds things up if I have the driver thread do it.

I fully expected us to be, at this point, talking about putting the pending softirq check back into the trap return path :-/

Quoted 2 lines · David Miller

I fully expected us to be, at this point, talking about putting the pending softirq check back into the trap return path :-/

Would that actually do any good, in the case where the system has decided that ksoftirqd is handling soft irqs at the moment?

Wouldn't the even better solution be to get rid of softirqs all-together?

One of the reasons I brought up this issue is that there is a lot of documentation out there that says "softirqs will be processed on return from a syscall". The fact that it actually depends on the scheduler parameters of the task issuing the syscall isn't ever mentioned.

In fact, "Documentation/DocBook/kernel-hacking.tmpl" in the kernel source still has the following:

Whenever a system call is about to return to userspace, or a hardware interrupt handler exits, any 'software interrupts' which are marked pending (usually by hardware interrupts) are run (<filename>kernel/softirq.c</filename>).

If anyone is looking at changing this code, it might be good to ensure that at least the kernel docs are updated.

Quoted 4 lines · Chris Friesen

One of the reasons I brought up this issue is that there is a lot of documentation out there that says "softirqs will be processed on return from a syscall". The fact that it actually depends on the scheduler parameters of the task issuing the syscall isn't ever mentioned.

It's not mentioned because it is not currently.

"If a soft irq is raised in process context, raise_softirq() in kernel/softirq.c calls wakeup_softirqd() to make sure that ksoftirqd

Quoted 2 lines

"If a soft irq is raised in process context, raise_softirq() in kernel/softirq.c calls wakeup_softirqd() to make sure that ksoftirqd

softirqd is only used when the softirq runs for too long or when there are no suitable irq exits for a long time.

In normal situations (not excessive time in softirq) they don't do anything.

Err, no. Chris is completely correct:

        if (!in_interrupt())
		wakeup_softirqd();

We can not rely on irqs coming in when the softirq is raised from

Quoted 4 lines · Thomas Gleixner

Err, no. Chris is completely correct:

        if (!in_interrupt())
		wakeup_softirqd();

Yes you have to wake it up just in case, but it doesn't normally process the data because a normal softirq comes in faster. It's just a safety policy.

You can check this by checking the accumulated CPU time on your ksoftirqs. Mine are all 0 even on long running systems.

The reason Andrea originally added the softirqds was just that if you have very softirq intensive workloads they would tie up too much CPU time or not make enough process with the default "don't loop too often" heuristics.

Quoted 1 line

We can not rely on irqs coming in when the softirq is raised from

You can't rely on it, but it happens in near all cases.

-Andi

I have one machine SMP flooded by network frames, CPU0 handling all

Quoted 4 lines · Thomas Gleixner

Err, no. Chris is completely correct:

       if (!in_interrupt())
		wakeup_softirqd();

Yes you have to wake it up just in case, but it doesn't normally process the data because a normal softirq comes in faster. It's just a safety policy.

Quoted 10 lines · Andi Kleen

Quoted 4 lines · Thomas Gleixner

Err, no. Chris is completely correct:

       if (!in_interrupt())
		wakeup_softirqd();

Yes you have to wake it up just in case, but it doesn't normally process the data because a normal softirq comes in faster. It's just a safety policy.

What about the scenario I raised earlier, where we have incoming network packets, no hardware interrupts coming in other than the timer tick, and a high-priority userspace app is spinning on recvmsg() with MSG_DONTWAIT set?

As far as I can tell, in this scenario softirqs may not get processed on return from a syscall (contradicting the documentation). In the worst case, they may not get processed until the next timer tick.

Quoted 3 lines · Chris Friesen

As far as I can tell, in this scenario softirqs may not get processed on return from a syscall (contradicting the documentation). In the worst case, they may not get processed until the next timer tick.

Right because your high prio tasks prevents that ksoftirqd runs, because it can not preempt the high priority task.

Quoted 7 lines · Andi Kleen

Quoted 4 lines · Thomas Gleixner

Err, no. Chris is completely correct:

       if (!in_interrupt())
		wakeup_softirqd();

Quoted 3 lines

Yes you have to wake it up just in case, but it doesn't normally process the data because a normal softirq comes in faster. It's just a safety policy.

What about the scenario I raised earlier, where we have incoming network packets,

network packets are normally processed by the network packet interrupt's softirq or alternatively in the NAPI poll loop.

Quoted 2 lines · Andi Kleen

network packets are normally processed by the network packet interrupt's softirq or alternatively in the NAPI poll loop.

If we have a high priority task, ksoftirqd may not get a chance to run.

Quoted 5 lines · Chris Friesen

Quoted 2 lines · Andi Kleen

network packets are normally processed by the network packet interrupt's softirq or alternatively in the NAPI poll loop.

If we have a high priority task, ksoftirqd may not get a chance to run.

In this case the next interrupt will also process them. It will just go more slowly because interrupts limit the work compared to ksoftirqd.

Quoted 5 lines · Andi Kleen

Quoted 4 lines · Chris Friesen

Quoted 2 lines · Andi Kleen

network packets are normally processed by the network packet interrupt's softirq or alternatively in the NAPI poll loop.

Quoted 4 lines

Quoted 1 line

If we have a high priority task, ksoftirqd may not get a chance to run.

In this case the next interrupt will also process them. It will just go more slowly because interrupts limit the work compared to ksoftirqd.

I realize that they will eventually get processed. My point is that the documentation (in-kernel, online, and in various books) says that softirqs will be processed _on the return from a syscall_.

Quoted 8 lines · Chris Friesen

Quoted 7 lines · Andi Kleen

Quoted 5 lines · Chris Friesen

Quoted 2 lines · Andi Kleen

network packets are normally processed by the network packet interrupt's softirq or alternatively in the NAPI poll loop.

If we have a high priority task, ksoftirqd may not get a chance to run.

Quoted 6 lines

Quoted 2 lines

In this case the next interrupt will also process them. It will just go more slowly because interrupts limit the work compared to ksoftirqd.

I realize that they will eventually get processed. My point is that the documentation (in-kernel, online, and in various books) says that softirqs will be processed _on the return from a syscall_.

They are. The documentation is correct.