On Wed, Aug 28, 2019 at 01:23:06PM +0200, Thomas Gleixner wrote: > 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. This patch still works even though the only clocksource is jiffies. > > > > 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. >From the code of kernel/irq/timing.c: 1) record_irq_time() only records the start time of one irq, and not consider the time taken in interrupt handler, so we can't figure out the real interval between two do_IRQ() on one CPU 2) irq/timing doesn't cover softirq Daniel, could you take a look and see if irq flood detection can be implemented easily by irq/timing.c? thanks, Ming
