softirq: Per vector threading v3

For now, vectors that get re-enqueued trigger ksoftirqd but they are going to be handled by per-vector workqueues on subsequent patches.

So this "get requeued" condition I think will trigger always for networking tunnel decapsulation.

Quoted 3 lines

So this "get requeued" condition I think will trigger always for networking tunnel decapsulation.

Hmm. Interesting and a perhaps bit discouraging.

Will it always be just a _single_ level of indirection, or will double tunnels (I assume some people do that, just because the universe is out to get us) then result in this perhaps repeating several times?

From: Linus Torvalds <[email protected]>
Date: Fri, 19 Jan 2018 10:25:03 -0800

Quoted 7 lines · David Miller

Quoted 3 lines

So this "get requeued" condition I think will trigger always for networking tunnel decapsulation.

Hmm. Interesting and a perhaps bit discouraging.

Quoted 3 lines

Will it always be just a _single_ level of indirection, or will double tunnels (I assume some people do that, just because the universe is out to get us) then result in this perhaps repeating several times?

Every level of tunnel encapsulation will trigger a new softirq.

So if you have an IP tunnel inside of an IP tunnel that will trigger twice.

Quoted 14 lines

From: Linus Torvalds <[email protected]>
Date: Fri, 19 Jan 2018 10:25:03 -0800

Quoted 10 lines · David Miller

Quoted 3 lines

So this "get requeued" condition I think will trigger always for networking tunnel decapsulation.

Hmm. Interesting and a perhaps bit discouraging.

Will it always be just a _single_ level of indirection, or will double tunnels (I assume some people do that, just because the universe is out to get us) then result in this perhaps repeating several times?

Quoted 4 lines

Every level of tunnel encapsulation will trigger a new softirq.

So if you have an IP tunnel inside of an IP tunnel that will trigger twice.

So we may likely need to come back to a call counter based limit :-s

Some softirq vectors can be more CPU hungry than others. Especially networking may sometimes deal with packet storm and need more CPU than IRQ tail can offer without inducing scheduler latencies. In this case the current code defers to ksoftirqd that behaves nicer. Now this nice behaviour can be bad for other IRQ vectors that usually need quick processing.

To solve this we only defer to threading the vectors that got re-enqueued on IRQ tail processing and leave the others inline on IRQ tail service. This is achieved using workqueues with per-CPU/per-vector worklets.

Note ksoftirqd is not yet removed as it is still needed for threaded IRQs mode.

kernel/softirq.c +12 -0

+static void do_softirq_workqueue(u32 pending)
+{
+	struct softirq *softirq = this_cpu_ptr(&softirq_cpu);
+	struct softirq_action *h = softirq_vec;
+	int softirq_bit;
+
+	pending &= ~softirq->pending_work_mask;
+
+	while ((softirq_bit = ffs(pending))) {
+		struct vector *vector;
+		unsigned int vec_nr;
+

I have couple questions/comments.

(1) Since the work is queued on a bounded per-cpu worker, we may run into a deadlock if a TASKLET is killed from another work running on the same bounded per-cpu worker.

For example,

(1) Schedule a TASKLET on CPU#0 from IRQ.
(2) Another IRQ comes on the same CPU and we queue a work to kill the TASKLET.
(3) The TASKLET vector is deferred to workqueue.
(4) We run the TASKLET kill work and wait for the TASKLET to finish, which won't happen.

We can fix this by queueing the TASKLET kill work on an unbounded workqueue so that this runs in parallel with TASKLET vector work.

Just wanted to know if we have to be aware of this *condition*.

(2) Ksoftirqd thread gets parked when a CPU is hotplugged out. So there is a gaurantee that the softirq handling never happens on another CPU. Where as a bounded worker gets detached and the queued work can run on another CPU. I guess, some special handling is needed to handle hotplug.

On Sat, Jan 20, 2018 at 02:11:39PM +0530, Pavan Kondeti wrote:

Hi Pavan,

Quoted 15 lines

I have couple questions/comments.

(1) Since the work is queued on a bounded per-cpu worker, we may run into a deadlock if a TASKLET is killed from another work running on the same bounded per-cpu worker.

For example,

(1) Schedule a TASKLET on CPU#0 from IRQ.
(2) Another IRQ comes on the same CPU and we queue a work to kill the TASKLET.
(3) The TASKLET vector is deferred to workqueue.
(4) We run the TASKLET kill work and wait for the TASKLET to finish, which won't happen.

Quoted 4 lines

We can fix this by queueing the TASKLET kill work on an unbounded workqueue so that this runs in parallel with TASKLET vector work.

Just wanted to know if we have to be aware of this *condition*.

But IIRC the workqueues have several workers per CPU so the tasklet to be killed can run while the tasklet killer yields.

Quoted 25 lines · Frederic Weisbecker

On Sat, Jan 20, 2018 at 02:11:39PM +0530, Pavan Kondeti wrote:

Hi Pavan,

Quoted 19 lines

I have couple questions/comments.

(1) Since the work is queued on a bounded per-cpu worker, we may run into a deadlock if a TASKLET is killed from another work running on the same bounded per-cpu worker.

For example,

(1) Schedule a TASKLET on CPU#0 from IRQ.
(2) Another IRQ comes on the same CPU and we queue a work to kill the TASKLET.
(3) The TASKLET vector is deferred to workqueue.
(4) We run the TASKLET kill work and wait for the TASKLET to finish, which won't happen.

We can fix this by queueing the TASKLET kill work on an unbounded workqueue so that this runs in parallel with TASKLET vector work.

Just wanted to know if we have to be aware of this *condition*.

Quoted 3 lines

But IIRC the workqueues have several workers per CPU so the tasklet to be killed can run while the tasklet killer yields.

AFAIK, the work items queued via schedule_work_on() goes to the system_wq which is bounded to a CPU with concurrency restrictions. If any work item (in this case tasklet kill) is getting executed on this bounded worker, the next items have to wait. The forward progress happens only when the current work is finished or enters sleep.

This also makes me wonder what happens if a CPU hogging work gets executed on the system_wq while softirq work is pending? The softirq work gets starved which won't happen now with ksoftirqd design. Ideally the CPU hogging work should not be queued on the system_wq and instead should be queued on CPU intenstive workqueue (WQ_CPU_INTENSIVE) to exempt from concurrency management. May be we need some special workqueue which is bounded but not subjected to concurrency management.

Signature · 2 lines

Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

kernel/softirq.c +0 -0

index c8c6841..becb1d9 100644
@@ -62,6 +62,19 @@ const char * const softirq_to_name[NR_SOFTIRQS] = {

kernel/softirq.c +13 -0

+static void vector_work_func(struct work_struct *work)
+{
+	struct vector *vector = container_of(work, struct vector, work);
+	struct softirq *softirq = this_cpu_ptr(&softirq_cpu);
+	int vec_nr = vector->nr;
+	int vec_bit = BIT(vec_nr);
+	u32 pending;
+
+	local_irq_disable();
+	pending = local_softirq_pending();
+	account_irq_enter_time(current);
+	__local_bh_disable_ip(_RET_IP_, SOFTIRQ_OFFSET);
+	lockdep_softirq_enter();

May I instead suggest to stick to ksoftirqd? So you run in softirq context (after return from IRQ) and if takes too long, you offload the vector to ksoftirqd instead. You may want to play with the metric on which you decide when you want switch to ksoftirqd / account how long a vector runs.

From: Sebastian Andrzej Siewior <[email protected]>
Date: Thu, 8 Feb 2018 18:44:52 +0100

Quoted 2 lines

May I instead suggest to stick to ksoftirqd? So you run in softirq context (after return from IRQ) and if takes too long, you offload

the

Quoted 1 line

vector to ksoftirqd instead. You may want to play with the metric

on

Quoted 1 line

which you decide when you want switch to ksoftirqd / account how

long a

Quoted 1 line

vector runs.

Having read over this stuff for the past few weeks this is how I feel as well. Just make ksofbitrq do what we want (only execute the overloaded softirq vectors).

The more I look at the workqueue stuff, the more complications and weird behavioral artifacts we are getting for questionable gain.

Quoted 16 lines

From: Sebastian Andrzej Siewior <[email protected]>
Date: Thu, 8 Feb 2018 18:44:52 +0100

Quoted 2 lines

May I instead suggest to stick to ksoftirqd? So you run in softirq context (after return from IRQ) and if takes too long, you offload

the

Quoted 1 line

vector to ksoftirqd instead. You may want to play with the metric

on

Quoted 1 line

which you decide when you want switch to ksoftirqd / account how

long a

Quoted 1 line

vector runs.

Having read over this stuff for the past few weeks this is how I feel as well. Just make ksofbitrq do what we want (only execute the overloaded softirq vectors).

Quoted 2 lines

The more I look at the workqueue stuff, the more complications and weird behavioral artifacts we are getting for questionable gain.

What about creating several ksoftirqd threads per-cpu? Like I did with boot parameter to specify how many threads and which softirqs to serve.

From: Dmitry Safonov <[email protected]>
Date: Thu, 08 Feb 2018 20:14:55 +0000

Quoted 5 lines · David Miller

Quoted 4 lines

From: Sebastian Andrzej Siewior <[email protected]>
Date: Thu, 8 Feb 2018 18:44:52 +0100

Quoted 1 line

May I instead suggest to stick to ksoftirqd? So you run in

softirq

Quoted 1 line

Quoted 1 line

Quoted 1 line

context (after return from IRQ) and if takes too long, you

offload

Quoted 2 lines

Quoted 2 lines

the

Quoted 1 line

vector to ksoftirqd instead. You may want to play with the

metric

Quoted 6 lines

Quoted 6 lines

on

Quoted 1 line

which you decide when you want switch to ksoftirqd / account how

long a

Quoted 1 line

vector runs.

Having read over this stuff for the past few weeks this is how I

feel

Quoted 6 lines

Quoted 5 lines

as well. Just make ksofbitrq do what we want (only execute the overloaded softirq vectors).

The more I look at the workqueue stuff, the more complications and weird behavioral artifacts we are getting for questionable gain.

Quoted 2 lines

What about creating several ksoftirqd threads per-cpu? Like I did with boot parameter to specify how many threads and

which

Quoted 1 line

softirqs to serve.

Why do we need more than one per cpu?

There is a set of vectors which are "overloaded" and ksoftirqd processes
them one by one.

The only difference with what happens now is that one softirq being overloaded doesn't defer the processing of all softirqs to ksoftirqd.

Quoted 30 lines · David Miller

From: Dmitry Safonov <[email protected]>
Date: Thu, 08 Feb 2018 20:14:55 +0000

Quoted 5 lines · David Miller

Quoted 4 lines

From: Sebastian Andrzej Siewior <[email protected]>
Date: Thu, 8 Feb 2018 18:44:52 +0100

Quoted 1 line

May I instead suggest to stick to ksoftirqd? So you run in

softirq

Quoted 1 line

Quoted 1 line

Quoted 1 line

context (after return from IRQ) and if takes too long, you

offload

Quoted 2 lines

Quoted 2 lines

the

Quoted 1 line

vector to ksoftirqd instead. You may want to play with the

metric

Quoted 6 lines

Quoted 6 lines

on

Quoted 1 line

which you decide when you want switch to ksoftirqd / account how

long a

Quoted 1 line

vector runs.

Having read over this stuff for the past few weeks this is how I

feel

Quoted 8 lines

Quoted 5 lines

as well. Just make ksofbitrq do what we want (only execute the overloaded softirq vectors).

The more I look at the workqueue stuff, the more complications and weird behavioral artifacts we are getting for questionable gain.

What about creating several ksoftirqd threads per-cpu? Like I did with boot parameter to specify how many threads and

which

Quoted 3 lines

Quoted 1 line

softirqs to serve.

Why do we need more than one per cpu?

Ugh, yeah, I remember why I did it - I tried to reuse scheduler for each ksoftirqd thread to decide if it need to run now or later. That would give an admin a way to prioritise softirqs with nice. Not sure if it's a nice idea at all..

Quoted 7 lines · Dmitry Safonov

Quoted 1 line · David Miller

Why do we need more than one per cpu?

Ugh, yeah, I remember why I did it - I tried to reuse scheduler for each ksoftirqd thread to decide if it need to run now or later. That would give an admin a way to prioritise softirqs with nice. Not sure if it's a nice idea at all..

For RT that can be handy, but for the general case it's a waste of cycles, so would want to be opt-in.

-Mike

Quoted 5 lines · Frederic Weisbecker

kernel/softirq.c +0 -0

index c8c6841..becb1d9 100644
@@ -62,6 +62,19 @@ const char * const softirq_to_name[NR_SOFTIRQS] = {

…

Quoted 13 lines

kernel/softirq.c +13 -0

+static void vector_work_func(struct work_struct *work)
+{
+	struct vector *vector = container_of(work, struct vector, work);
+	struct softirq *softirq = this_cpu_ptr(&softirq_cpu);
+	int vec_nr = vector->nr;
+	int vec_bit = BIT(vec_nr);
+	u32 pending;
+
+	local_irq_disable();
+	pending = local_softirq_pending();
+	account_irq_enter_time(current);
+	__local_bh_disable_ip(_RET_IP_, SOFTIRQ_OFFSET);
+	lockdep_softirq_enter();

kernel/softirq.c static inline bool lockdep_softirq_start(void) { return false; } · line 266

Quoted 10 lines

kernel/softirq.c +10 -0

+	set_softirq_pending(pending & ~vec_bit);
+	local_irq_enable();
+
+	if (pending & vec_bit) {
+		struct softirq_action *sa = &softirq_vec[vec_nr];
+
+		kstat_incr_softirqs_this_cpu(vec_nr);
+		softirq->work_running = 1;
+		trace_softirq_entry(vec_nr);
+		sa->action(sa);

You invoke the softirq handler while BH is disabled (not wrong, I just state the obvious). That means, the scheduler can't preempt/interrupt the workqueue/BH-handler while it is invoked so it has to wait until it

completes its doing.
In do_softirq_workqueue() you schedule multiple workqueue items (one for each softirq vector) which is unnecessary because they can't preempt one another and should be invoked the order they were enqueued. So it would be enough to enqueue one item because it is serialized after all. So one work_struct per CPU with a cond_resched_rcu_qs() while switching from one vector to another should accomplish that what you have now here (not sure if that cond_resched after each vector is needed). But…

kernel/softirq.c static inline bool lockdep_softirq_start(void) { return false; } · line 275

Quoted 10 lines

kernel/softirq.c +9 -0

+		trace_softirq_exit(vec_nr);
+		softirq->work_running = 0;
+	}
+
+	local_irq_disable();
+
+	pending = local_softirq_pending();
+	if (pending & vec_bit)
+		schedule_work_on(smp_processor_id(), &vector->work);

… on a system that is using system_wq a lot, it might introduced a certain latency until your softirq-worker gets its turn. The workqueue will spawn new workers if the current worker schedules out but until that happens you have to wait. I am not sure if this is intended or whether this might be a problem. I think you could argue either way depending on what you currently think is more important.

Further, schedule_work_on(x, ) does not guarentee that the work item is invoked on CPU x. It tries that but if CPU x goes down due to CPU-hotplug then the workitem will be moved to random CPU. For that reason we have work_on_cpu_safe() but you don't want to use that / flush that workqueue while in here.

May I instead suggest to stick to ksoftirqd? So you run in softirq context (after return from IRQ) and if takes too long, you offload the vector to ksoftirqd instead. You may want to play with the metric on which you decide when you want switch to ksoftirqd / account how long a vector runs.

Yeah that makes sense. These workqueues are too much headaches eventually. I'm going to try that ksoftirqd thing.

Thanks.

As per Linus suggestion, this take doesn't limit the number of occurences per jiffy anymore but instead defers a vector to workqueues as soon as it gets re-enqueued on IRQ tail.

No tunable here, so testing should be easier.

git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
softirq/thread-v3

HEAD: 6835e92cbd70ef4a056987d2e1ed383b294429d4

Thanks,
Frederic
---

Frederic Weisbecker (4):
softirq: Limit vector to a single iteration on IRQ tail
softirq: Per vector deferment to workqueue
softirq: Defer to workqueue when rescheduling is needed
softirq: Replace ksoftirqd with workqueues entirely

 Documentation/RCU/stallwarn.txt |   4 +-
 include/linux/interrupt.h       |   7 +-
 kernel/sched/cputime.c          |  12 +--
 kernel/sched/sched.h            |   4 +-
 kernel/softirq.c                | 223 +++++++++++++++++++++++-----------------
 net/ipv4/tcp_output.c           |   5 +-
 6 files changed, 144 insertions(+), 111 deletions(-)

As per Linus suggestion, this take doesn't limit the number of occurences per jiffy anymore but instead defers a vector to workqueues as soon as it gets re-enqueued on IRQ tail.

No tunable here, so testing should be easier.

git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
softirq/thread-v3

HEAD: 6835e92cbd70ef4a056987d2e1ed383b294429d4

Hi,

Quoted 6 lines · Frederic Weisbecker

As per Linus suggestion, this take doesn't limit the number of occurences
per jiffy anymore but instead defers a vector to workqueues as soon as
it gets re-enqueued on IRQ tail.

Quoted 7 lines

No tunable here, so testing should be easier.

git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-
dynticks.git
softirq/thread-v3

HEAD: 6835e92cbd70ef4a056987d2e1ed383b294429d4

I tested this series in the UDP flood scenario, binding the user space
process receiving the packets on the same CPU processing the related IRQ, and the tput sinks nearly to 0, like before Eric's patch.

The perf tool says that almost all the softirq processing is done inside the workqueue, but the user space process is scheduled very rarely, while before this series, in this scenario, ksoftirqd and the user space process got a fair share of the CPU time.

Quoted 22 lines · Paolo Abeni

Hi,

Quoted 6 lines · Frederic Weisbecker

As per Linus suggestion, this take doesn't limit the number of occurences
per jiffy anymore but instead defers a vector to workqueues as soon as
it gets re-enqueued on IRQ tail.

Quoted 7 lines

No tunable here, so testing should be easier.

git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-
dynticks.git
softirq/thread-v3

HEAD: 6835e92cbd70ef4a056987d2e1ed383b294429d4

I tested this series in the UDP flood scenario, binding the user space
process receiving the packets on the same CPU processing the related IRQ, and the tput sinks nearly to 0, like before Eric's patch.

Quoted 4 lines

The perf tool says that almost all the softirq processing is done inside the workqueue, but the user space process is scheduled very rarely, while before this series, in this scenario, ksoftirqd and the user space process got a fair share of the CPU time.

It get a fair share of the CPU time only on some lucky platforms (maybe on the most). On other not-so-lucky platforms it was also unfair - as I've previously described by the reason of slow raising softirqs :-/

Hi,

Quoted 10 lines · Frederic Weisbecker

As per Linus suggestion, this take doesn't limit the number of occurences per jiffy anymore but instead defers a vector to workqueues as soon as it gets re-enqueued on IRQ tail.

No tunable here, so testing should be easier.

git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
softirq/thread-v3

HEAD: 6835e92cbd70ef4a056987d2e1ed383b294429d4

I tested this series in the UDP flood scenario, binding the user space process receiving the packets on the same CPU processing the related IRQ, and the tput sinks nearly to 0, like before Eric's patch.

The perf tool says that almost all the softirq processing is done inside the workqueue, but the user space process is scheduled very rarely, while before this series, in this scenario, ksoftirqd and the user space process got a fair share of the CPU time.

From: Paolo Abeni <[email protected]>
Date: Tue, 23 Jan 2018 11:13:52 +0100

Quoted 18 lines

Hi,

Quoted 10 lines · Frederic Weisbecker

As per Linus suggestion, this take doesn't limit the number of occurences per jiffy anymore but instead defers a vector to workqueues as soon as it gets re-enqueued on IRQ tail.

No tunable here, so testing should be easier.

git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
softirq/thread-v3

HEAD: 6835e92cbd70ef4a056987d2e1ed383b294429d4

I tested this series in the UDP flood scenario, binding the user space process receiving the packets on the same CPU processing the related IRQ, and the tput sinks nearly to 0, like before Eric's patch.

Quoted 4 lines

The perf tool says that almost all the softirq processing is done inside the workqueue, but the user space process is scheduled very rarely, while before this series, in this scenario, ksoftirqd and the user space process got a fair share of the CPU time.

Do workqueue threads get a higher scheduling priority than user processes?

Or is it that the workqueue execution is simply not yielding for some reason?

Quoted 3 lines

Or is it that the workqueue execution is simply not yielding for some reason?

It's like that.

I spent little time on it, so I haven't many data point. I'll try to investigate the scenario later this week.

Quoted 8 lines · Paolo Abeni

Quoted 3 lines

Or is it that the workqueue execution is simply not yielding for some reason?

It's like that.

I spent little time on it, so I haven't many data point. I'll try to investigate the scenario later this week.

Hmm. workqueues seem to use cond_resched_rcu_qs(), which does a cond_resched() (and a RCU quiescent note).

But I wonder if the test triggers the "lets run lots of workqueue threads", and then the single-threaded user space just gets blown out of the water by many kernel threads. Each thread gets its own "fair" amount of CPU, but..

But I wonder if the test triggers the "lets run lots of workqueue threads", and then the single-threaded user space just gets blown out of the water by many kernel threads. Each thread gets its own "fair" amount of CPU, but..

From: Linus Torvalds <[email protected]>
Date: Tue, 23 Jan 2018 09:42:32 -0800

Quoted 4 lines

But I wonder if the test triggers the "lets run lots of workqueue threads", and then the single-threaded user space just gets blown out of the water by many kernel threads. Each thread gets its own "fair" amount of CPU, but..

If a single cpu's softirq deferral can end up running on multiple workqueue threads, indeed that's a serious problem.

So if we're in a workqueue and it does a:

	schedule_work_on(this_cpu, currently_executing_work);

it'll potentially make a new thread?

That's exactly the code path that will get exercised during a UDP flood the way that vector_work_func() is implemented.

Quoted 17 lines

From: Linus Torvalds <[email protected]>
Date: Tue, 23 Jan 2018 09:42:32 -0800

Quoted 4 lines

But I wonder if the test triggers the "lets run lots of workqueue threads", and then the single-threaded user space just gets blown out of the water by many kernel threads. Each thread gets its own "fair" amount of CPU, but..

If a single cpu's softirq deferral can end up running on multiple workqueue threads, indeed that's a serious problem.

So if we're in a workqueue and it does a:

	schedule_work_on(this_cpu, currently_executing_work);

it'll potentially make a new thread?

Quoted 2 lines

That's exactly the code path that will get exercised during a UDP flood the way that vector_work_func() is implemented.

It shouldn't create a new thread unless all other workers in the CPU are voluntarily sleeping while executing a work. Also since softirqs can't sleep, we shouldn't even have two vectors running concurrently on workqueues.

Quoted 8 lines · Paolo Abeni

Quoted 3 lines

Or is it that the workqueue execution is simply not yielding for some reason?

It's like that.

I spent little time on it, so I haven't many data point. I'll try to investigate the scenario later this week.

Hmm. workqueues seem to use cond_resched_rcu_qs(), which does a cond_resched() (and a RCU quiescent note).

But I wonder if the test triggers the "lets run lots of workqueue threads", and then the single-threaded user space just gets blown out of the water by many kernel threads. Each thread gets its own "fair" amount of CPU, but..

Niklas suggested a possible relation with CONFIG_IRQ_TIME_ACCOUNTING=y and indeed he was right.

The patched kernel under test had CONFIG_IRQ_TIME_ACCOUNTING set, and very little CPU time was accounted to the kworker:

[2125 is the relevant kworker's pid]
grep sum_exec_runtime /proc/2125/sched; sleep 10; grep sum_exec_runtime /proc/2125/sched

se.sum_exec_runtime                          :         13408.239286
se.sum_exec_runtime                          :         13456.907197

despite such process was processing a lot of packets and basically burning a CPU.

From: Paolo Abeni <[email protected]>
Date: Wed, 24 Jan 2018 15:54:05 +0100

Quoted 11 lines

Niklas suggested a possible relation with CONFIG_IRQ_TIME_ACCOUNTING=y and indeed he was right.

The patched kernel under test had CONFIG_IRQ_TIME_ACCOUNTING set, and very little CPU time was accounted to the kworker:

[2125 is the relevant kworker's pid]
grep sum_exec_runtime /proc/2125/sched; sleep 10; grep sum_exec_runtime /proc/2125/sched

se.sum_exec_runtime                          :         13408.239286
se.sum_exec_runtime                          :         13456.907197

Quoted 2 lines

despite such process was processing a lot of packets and basically burning a CPU.

So IRQ_TIME_ACCOUNTING makes the scheduler think that the worker threads are using nearly no task time at all.

The existing ksoftirqd code should hit the same problem, right?

As per Linus suggestion, this take doesn't limit the number of occurences per jiffy anymore but instead defers a vector to workqueues as soon as it gets re-enqueued on IRQ tail.

No tunable here, so testing should be easier.

Em Fri, 19 Jan 2018 16:46:10 +0100
Frederic Weisbecker <[email protected]> escreveu:

Quoted 4 lines

As per Linus suggestion, this take doesn't limit the number of occurences per jiffy anymore but instead defers a vector to workqueues as soon as it gets re-enqueued on IRQ tail.

Quoted 1 line

No tunable here, so testing should be easier.

Sorry for taking so long to test it. Just returned this week from a 2 weeks travel, and had first to submit media patches for the merge window.

Didn't work. With this patch series, it still lose frames with usb bulk transfers, while recording DVB programs with tvheadend.