From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935102AbdKPNos (ORCPT ); Thu, 16 Nov 2017 08:44:48 -0500 Received: from mx2.suse.de ([195.135.220.15]:32966 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935076AbdKPNoc (ORCPT ); Thu, 16 Nov 2017 08:44:32 -0500 Date: Thu, 16 Nov 2017 14:44:30 +0100 From: Michal Hocko To: "Reshetova, Elena" Cc: Peter Zijlstra , "linux-kernel@vger.kernel.org" , "gregkh@linuxfoundation.org" , "keescook@chromium.org" , "tglx@linutronix.de" , "mingo@redhat.com" , "ishkamiel@gmail.com" , Will Deacon , Paul McKenney , "stern@rowland.harvard.edu" , "parri.andrea@gmail.com" , "boqun.feng@gmail.com" , "dhowells@redhat.com" , "david@fromorbit.com" Subject: Re: [PATCH] refcount: provide same memory ordering guarantees as in atomic_t Message-ID: <20171116134430.kbc2x2yryx7546z6@dhcp22.suse.cz> References: <1508756984-18980-1-git-send-email-elena.reshetova@intel.com> <20171023131224.GC3165@worktop.lehotels.local> <2236FBA76BA1254E88B949DDB74E612B802B6A2E@IRSMSX102.ger.corp.intel.com> <20171027135624.GY3165@worktop.lehotels.local> <2236FBA76BA1254E88B949DDB74E612B802B89B8@IRSMSX102.ger.corp.intel.com> <20171102135742.7o4urtltgvhr6dku@hirez.programming.kicks-ass.net> <2236FBA76BA1254E88B949DDB74E612B802BC4BA@IRSMSX102.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2236FBA76BA1254E88B949DDB74E612B802BC4BA@IRSMSX102.ger.corp.intel.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 13-11-17 09:09:57, Reshetova, Elena wrote: > > > > Note that there's work done on better documents and updates to this one. > > One document that might be good to read (I have not in fact had time to > > read it myself yet :-(): > > > > https://github.com/aparri/memory- > > model/blob/master/Documentation/explanation.txt > > > > I have just finished reading over this and must say that this is excellent. I fully second this. The main problem with Documentation/memory-barriers.txt is that it jumps from "easy to follow" to "blow your head" parts is just too quick. On the other hand the above explanation builds the picture from basics and piles up new layers on top of previous. So I found it much more easier to grasp. I cannot really speak for the correctness in all aspects but it certainly makes a lot of sense to me. If you are really interested then feel free to add. Acked-by: Michal Hocko -- Michal Hocko SUSE Labs