[Devel] [RFC rh7 v2] ve/tty: vt -- Implement per VE support for virtual consoles

[Cyrill Gorcunov]

On 07/31/2015 03:13 PM, Vladimir Davydov wrote:
> On Fri, Jul 31, 2015 at 02:48:54PM +0300, Cyrill Gorcunov wrote:
...
>>>
>>> What *exactly* can go wrong on any arch of your preference if you remove
>>> this smp_mb__before_clear_bit?
>>
>> In worst scenario the wake will be delayed for some time,
>> until change get propagated into other cpu (it will eventually
>> that's why I said that I don't expect tragedy here, and actually
>> on cpu with really weak ordering such as alpha it will propagate
>> as well). So by "wrong" here I mean a delay which I think we
>> can eliminate sith smp_mb helpers.
> 
> I don't mind *smp_mb__after_clear_bit* - it is necessary, but I do
> object against *smp_mb__before_clear_bit*, because I still don't see any
> point in it and your attempts to explain it only confuse me furthermore
> :-) That's why I keep asking you to describe what exactly will go wrong
> w/o it - I mean something like:
> 
> CPU1		CPU2
> ----		----
> BLAH
> 		BLAH-BLAH
> BUG

Ah, you mean why two helpers used instead of a single one ;)
In short (after more thinking) this is not needed (if we
had a number of different bits to touch then we would have
both barriers needed) but since it's only one flag dropping
"before" would be fine. I think I was confused by prt_clear_connecting
helper from xprt code. (And there won't be cpu1/cpu2 diagram
simply because the bit change will be propagated anyway
but simply with delay in worst case until cache line get
flushed :). I'll drop it off, thanks.


-- 
    Cyrill