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

[Byungchul Park <byungchul.park@lge.com>]

On 1/19/2018 12:21 AM, Steven Rostedt wrote:
> On Thu, 18 Jan 2018 13:01:46 +0900
> Byungchul Park <byungchul.park@lge.com> wrote:
> 
>>> 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 exactly what I was saying. Excuse me but, I don't understand
>> what you want to say. Could you explain more? What do you disagree?
> 
> I guess I'm confused at what you are asking for then.

Sorry for not enough explanation. What I asked you for is:

    1. Relocate acquire()s/release()s.
    2. So make it simpler and remove unnecessary one.
    3. So make it look like the following form,
       because it's a thing simulating "wait and event".

       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_release(wait);

       wait_for_event(wait); /* Actually do the wait */

Honestly, you used acquire()s/release()s as if they are cross-
release stuff which mainly handles general waits and events,
not only things doing "acquire -> critical area -> release".
But that's not in the mainline at the moment.

>>> I find your way confusing. I'm simulating a spinlock not a wait for
>>> completion. A wait for completion usually initiates something then
>>
>> I used the word, *event* instead of *completion*. wait_for_completion()
>> and complete() are just an example of a pair of waiter and event.
>> Lock and unlock can also be another example, too.
>>
>> Important thing is that who waits and who triggers the event. Using the
>> pair, we can achieve various things, for examples:
>>
>>      1. Synchronization like wait_for_completion() does.
>>      2. Control exclusively entering into a critical area.
>>      3. Whatever.
>>
>>> 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.
>>
>> Anyway it's an example of "waiter for an event, and the event".
>>
>> JFYI, spinning or sleeping does not matter. Those are just methods to
          ^
          whether spining or sleeping doesn't matter.

>> achieve a wait. I know you're not talking about this though. It's JFYI.
> 
> OK, if it is just FYI.

Actually, the last paragraph is JFYI tho.

> -- Steve
> 
> 
> 

-- 
Thanks,
Byungchul