On 2020-05-15 16:46:48 [-0700], Alison Chaiken wrote: > About a year ago the following commit greatly simplified softirqs: > > commit 6f6ba7715a91877cf5fd2b357db3799baa331d9b > Author: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> > Date: Wed May 29 18:47:32 2019 +0200 > softirq: rework > > It also removed ktimersoftd, without comment as far as I can see. Is > it obvious that performance improvements due to lockless > synchronization render useless the earlier split of ktimersoftd from > ksoftirqd? Is it now less likely that a large number of other > softirqs that are run immediately when hard IRQs terminate will use up > ksoftirqd's time slice and prevent the timer softirqs from getting a > chance to run? When hard IRQs terminate and raise the softirq then the ksoftirqd is woken up. The softirq may be processed by the thread _or_ by anything else that is running happens to process softirqs. That can be any force-threaded interrupt handler. In general nothing raises softirqs from hardirq context. One exception here are POSIX timer. The plan was to rework POSIX-timer code. Sebastian
