Re: [PATCH v3 09/22] kthread: Allow to cancel kthread work

From: Linus Torvalds
Date: Tue Nov 24 2015 - 15:24:04 EST


On Mon, Nov 23, 2015 at 2:58 PM, Tejun Heo <tj@xxxxxxxxxx> wrote:
>
> And the timer can do (ignoring the multiple worker support, do we even
> need that?)
>
> while (!trylock(worker)) {
> if (work->canceling)
> return;
> cpu_relax();
> }

No no no!

People, you need to learn that code like the above is *not*
acceptable. It's busy-looping on a spinlock, and constantly trying to
*write* to the spinlock.

It will literally crater performance on a multi-socket SMP system if
it ever triggers. We're talking 10x slowdowns, and absolutely
unacceptable cache coherency traffic.

These kinds of loops absolutely *have* to have the read-only part. The
"cpu_relax()" above needs to be a loop that just tests the lock state
by *reading* it, so the cpu_relax() needs to be replaced with
something like

while (spin_is_locked(lock)) cpu_relax();

instead (possibly just "spin_unlock_wait()" - but the explicit loop
might be worth it if you then want to check the "canceling" flag
independently of the lock state too).

In general, it's very dangerous to try to cook up your own locking
rules. People *always* get it wrong.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/