lkml.org 
[lkml]   [2018]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v5 1/2] printk: Add console owner and waiter logic to load balance console writes
From
Date
On 1/18/2018 11:19 AM, Steven Rostedt wrote:
> On Thu, 18 Jan 2018 10:53:37 +0900
> Byungchul Park <byungchul.park@lge.com> 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 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?

>>
>> 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

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
achieve a wait. I know you're not talking about this though. It's JFYI.

--
Thanks,
Byungchul

\
 
 \ /
  Last update: 2018-01-18 05:02    [W:0.182 / U:0.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site