On Wed, 28 Aug 2019, Ming Lei wrote: > 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. Works by some definition of works, right? > > 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 I said utilize and that means that the infrastructure can be used and extended. I did not say that it solves your problem, right? > 2) irq/timing doesn't cover softirq That's solvable, right? > Daniel, could you take a look and see if irq flood detection can be > implemented easily by irq/timing.c? I assume you can take a look as well, right? Thanks, tglx
