[Xenomai-core] Re: [patch] memory barriers in intr.c :: xnintr_lock/unlock()

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 1277 bytes --]

Dmitry Adamushko wrote:
>> Ok, I'm stopping further speculations here... Back to practice, so do we
>> go
>> > for smp_mb__before/after_atomic_* counterparts or live it as is? I
>> guess,
>> > those would be more optimal.
>> >
>>
>> As I said, I'm still not sure if we finally need it when we may use
>> per-cpu counters for efficiency reasons on the long-term. If this will
>> add code or - even more important - an interface (of the system layer)
>> that will soon be removed again...
> 
> 
> So could you reveal your vision of per-cpu counters in this scenario (or
> something in linux does use it under similar circumstances.. RCU?) At the
> first glance, it doesn't seem to be much better. Although, I haven't
> elaborated more thoroughly yet...

I was thinking about some SRCU-like mechanism with clear optimisation
focus on the reader-side. See this article for SRCU:

http://lwn.net/Articles/202847/

Having per-cpu counter would let SMP readers benefit - no need for
atomic ops then.

There is currently some discussion going on about refining the
implementation:

http://www.ussg.iu.edu/hypermail/linux/kernel/0611.2/0227.html

It looks to me that we are in the comfortable situation of being able to
avoid such extensions.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]