> On Mon, 23 Oct 2017, Reshetova, Elena wrote: > > > On Fri, 20 Oct 2017, Elena Reshetova wrote: > > > How did you make sure that these atomic operations have no other > > > serialization effect and can be replaced with refcount? > > > > What serialization effects? Are you taking about smth else than memory > > ordering? > > Well, the memory ordering constraints can be part of serialization > mechanisms. Unfortunately they are not well documented .... Would you be able to point to any documentation or examples of this? I would be happy to understand more, it is really not smth very straightforward. The reason I also don't want to confuse people even more with this ordering issue is that it can be different if you use arch. specific implementation vs. arch. independent. So, it is not as simple as to say "refcount_t would always result in weak memory ordering", it really depends what REFCOUNT config option is "on", what arch. you are running on etc. Nothing to add is that by default refount_t = atomic_t unless you start enabling the related configs... > > > For memory ordering my current hope is that we can just make refcount_t > > to use same strict atomic primitives and then it would not make any > > difference. I think this would be the simplest way for everyone since I > > think even some maintainers are having issues understanding all the > > implications of "relaxed" ordering. > > Well, that would make indeed the conversion simpler because then it is just > a drop in replacement. Albeit there might be some places which benefit of > the relaxed ordering as on some architectures strict ordering is expensive. Well refcount_t was not meant to provide any other benefits from atomic_t apart from better security guarantees and potentially better written code (less possibilities to do smth stupid with a smaller API). If someone really have an issue with speed, they should be enabling arch. specific refcount_t implementation for their arch. anyway and then it is hopefully does it the best possible/faster way. Best Regards, Elena. > > Thanks, > > tglx
