On Wed, 28 Aug 2019, Ming Lei wrote: > On Wed, Aug 28, 2019 at 01:09:44AM +0200, Thomas Gleixner wrote: > > > > Also how is that supposed to work when sched_clock is jiffies based? > > > > > > Good catch, looks ktime_get_ns() is needed. > > > > And what is ktime_get_ns() returning when the only available clocksource is > > jiffies? > > IMO, it isn't one issue. If the only clocksource is jiffies, we needn't to > expect high IO performance. Then it is fine to always handle the irq in > interrupt context or thread context. > > However, if it can be recognized runtime, irq_flood_detected() can > always return true or false. Right. The clocksource is determined at runtime. And if there is no high resolution clocksource then that function will return crap. > > No. Talk to Daniel. There is not going to be yet another ad hoc thingy just > > to make block happy. > > I just take a first glance at the code of 'interrupt timing', and its > motivation is to predicate of the next occurrence of interested interrupt > for use cases of PM, such as predicate wakeup time. > > And predication could be one much more difficult thing, and its implementation > requires to record more info: such as irq number, recent multiple irq timestamps, > that means its overhead is a bit high. Meantime IRQS_TIMINGS should only be set > on interested interrupt(s). Well, yes. But it's trivial enough to utilize parts of it for your purposes. > Daniel, correct me if I am wrong. Daniel could have replied, if you'd put him on Cc .... > In theory, this patch provides one simple generic mechanism for avoiding > IRQ flood/CPU lockup, which could be used for any devices, not only high > performance storage. Right, we can add a lot of things to the kernel which provide simple generic mechanisms for special purposes and if all of them are enabled then we are doing the same thing over and over. Thanks, tglx
