Re: [PATCH v5 1/2] printk: Add console owner and waiter logic to load balance console writes

From: Steven Rostedt
Date: Wed Jan 17 2018 - 21:20:06 EST


On Thu, 18 Jan 2018 10:53:37 +0900
Byungchul Park <byungchul.park@xxxxxxx> wrote:

> Hello,
>
> This is a thing simulating a wait for an event e.g.
> wait_for_completion() doing spinning instead of sleep, rather
> than a spinlock. I mean:
>
> This context
> ------------
> while (READ_ONCE(console_waiter)) /* Wait for the event */
> cpu_relax();
>
> Another context
> ---------------
> WRITE_ONCE(console_waiter, false); /* Event */

I disagree. It is like a spinlock. You can say a spinlock() that is
blocked is also waiting for an event. That event being the owner does a
spin_unlock().

>
> That's why I said this's the exact case of cross-release. Anyway
> without cross-release, we usually use typical acquire/release
> pairs to cover a wait for an event in the following way:
>
> A context
> ---------
> lock_map_acquire(wait); /* Or lock_map_acquire_read(wait) */
> /* Read one is better though.. */
>
> /* A section, we suspect, a wait for an event might happen. */
> ...
> lock_map_release(wait);
>
>
> The place actually doing the wait
> ---------------------------------
> lock_map_acquire(wait);
> lock_map_acquire(wait);
>
> wait_for_event(wait); /* Actually do the wait */
>
> You can see a simple example of how to use them by searching
> kernel/cpu.c with "lock_acquire" and "wait_for_completion".
>
> However, as I said, if you suspect that cpu_relax() includes
> the wait, then it's ok to leave it. Otherwise, I think it
> would be better to change it in the way I showed you above.

I find your way confusing. I'm simulating a spinlock not a wait for
completion. A wait for completion usually initiates something then
waits for it to complete. This is trying to get into a critical area
but another task is currently in it. It's simulating a spinlock as far
as I can see.

-- Steve