lkl: relax cpu during __ndelay()

[lrh2000]

__ndelay() spins until the timeout occurs. If interrupts come concurrently from another host thread, an irq_status bit will be set, but the handler will not be called during the spin. This behavior is unreasonable. At least, it differs from that of real Linux running on a bare-mental machine.

A driver may expect the device to raise an IRQ within a few microseconds, so it tries to spin and wait for it. This does not work without the commit.

Calling cpu_relax() explicitly can cause the handlers to fire. This is also a valid use of cpu_relax() because the CPU is spinning.

---

linux/arch/lkl/include/asm/processor.h

Lines 6 to 15 in 9c51103

	static inline void cpu_relax(void)
	{
	unsigned long flags;
	/* since this is usually called in a tight loop waiting for some
	* external condition (e.g. jiffies) lets run interrupts now to allow
	* the external condition to propagate */
	local_irq_save(flags);
	local_irq_restore(flags);
	}

[tavip]

LGTM, thanks @lrh2000!

[ddiss]

Looks good. Curious to see how this affects benchmarks.

[lrh2000]

Curious to see how this affects benchmarks.

Does any benchmark have spinning sleep as its hot path? I think that's unusual. A driver sometimes spins to wait for interrupts, but that shouldn't be common. It especially shouldn't occur on a hot path.

---

Meanwhile, thanks for your quick reviews @tavip @ddiss!

[tavip]

Curious to see how this affects benchmarks.

Does any benchmark have spinning sleep as its hot path? I think that's unusual. A driver sometimes spins to wait for interrupts, but that shouldn't be common. It especially shouldn't occur on a hot path.

I agree. @ddiss do you something specific in mind?

[ddiss]

Curious to see how this affects benchmarks.

Does any benchmark have spinning sleep as its hot path? I think that's unusual. A driver sometimes spins to wait for interrupts, but that shouldn't be common. It especially shouldn't occur on a hot path.

I agree. @ddiss do you something specific in mind?

Nothing specific. I was vaguely thinking of network and storage throttling / back-off, but I don't see any such callers.

[thehajime]

LGTM, thanks !