Messages in this thread |  | | Date | Sun, 21 Jan 2018 17:11:17 +0100 | From | Frederic Weisbecker <> | Subject | Re: [RFC PATCH 2/4] softirq: Per vector deferment to workqueue |
| |
On Sat, Jan 20, 2018 at 02:11:39PM +0530, Pavan Kondeti wrote:
Hi Pavan,
> 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*.
But IIRC the workqueues have several workers per CPU so the tasklet to be killed can run while the tasklet killer yields.
> > (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.
Good catch. Funny, I worried a bit about CPU hotplug but I assumed the pending CPU-bound worklets would be simply sync'ed before CPU gets down.
Breaking their CPU-bound properties doesn't look sane to me.
Anyway, I'll need to make a CPU hotplug hook.
Thanks for reporting that!
|  |