From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118718 invoked by alias); 27 Oct 2016 14:36:51 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 118699 invoked by uid 89); 27 Oct 2016 14:36:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=bearing X-HELO: mail-qk0-f182.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=gRj5NTMpG21tfI/Sl82hgJBeLcKv0lvwgIa7jFjssW0=; b=iXB6AVoPVym/QRp6V+JTei7Kk5GcVplx6WmRrIuxK7NbyTH7UsxlNub64kYwESXQzc CiY6jias0Bw7CtMdxvecagA5Qq84/s8xMfsnRpJygNjrabSYbMiQM8nl8yEvfo0aBQUA 9Um2SVmgjc6rPsXgqaTLYDttfhNtZokkkLFCQGXSzJEXExsEXs+Ew1RSUnRZmZmMVdQI PqQ+F+eNZKbMDOPyW7kxK0mdrAm1/QcFYI79lw0W2Oinogqz4rCaptkN1vBJSApNJWop zkJ37j5TWKMskAdHXNWljNFfn+b6phumEb0elDbWWE5vJGNys4y487P7Kk3cCm3j/SF2 p92A== X-Gm-Message-State: ABUngvc9w0tGnYMOKxuHdjpQd5hZWMsuNeAVCrLh1lpk0mbu/iGs316gGFr+wRiySyg6zQEb X-Received: by 10.55.163.138 with SMTP id m132mr6334896qke.88.1477578998125; Thu, 27 Oct 2016 07:36:38 -0700 (PDT) Subject: Re: Remove sparcv8 support To: Torvald Riegel , David Miller References: <5810C1A3.9030504@gaisler.com> <10b5e6a5-835d-8dc4-09c6-fc632e0736be@linaro.org> <20161026.144741.1659367414224835783.davem@davemloft.net> <1477565575.7146.199.camel@localhost.localdomain> Cc: adhemerval.zanella@linaro.org, andreas@gaisler.com, libc-alpha@sourceware.org, software@gaisler.com From: Carlos O'Donell Message-ID: <502720f6-3057-41f5-7832-4b219f5f729f@redhat.com> Date: Thu, 27 Oct 2016 14:36:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1477565575.7146.199.camel@localhost.localdomain> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00488.txt.bz2 On 10/27/2016 06:52 AM, Torvald Riegel wrote: > On Wed, 2016-10-26 at 14:47 -0400, David Miller wrote: >> From: Adhemerval Zanella >> Date: Wed, 26 Oct 2016 16:02:50 -0200 >> >>>> I am not sure it is as simple as that. Even if the kernel makes sure >>>> that an emulated CAS is atomic against another emulated CAS, it would >>>> not guarantee atomicity against a plain store instruction on a different >>>> CPU, right? For the emulated CAS to work on an SMP system I would think >>>> the atomic_store_relaxed and atomic_store_release functions would also >>>> need to be handled by the kernel, locking the write out when the CAS is >>>> emulated, to keep the interaction linearizable. >>>> >>> >>> I would expect kernel to emulate all the define atomic operation defined >>> in ISA to provide correct atomic semantic. I am not really sure how >>> feasible it would be, but the idea is from library standpoint running >>> on a machine with a emulated atomic provided by kernel is semantic >>> equal to running on a machine with hardware provided atomic. >>> >>> And I think it would be not feasible to keep pushing for C11 atomics >>> on glibc if we can not guarantee it. >> >> Plain stores would semantically not be allowed on such a shared value >> anyways. >> >> If atomicity is required, then nobody should do direct stores. Direct >> stores are unchecked and non-atomic. Whether the kernel implements >> the CAS or the cpu does it directly has no bearing on this issue. >> >> All entities should always use the CAS operation to modify such values. > > I'm not quite sure what you're trying to say, so I'll make a few general > comments that will hopefully help clarify. > > It is true that we do want to use the C11 memory model throughout glibc, > which means a data-race-freedom requirement for glibc code, which in > turn means having to use atomic operations (ie, atomic_* ()) whenever > there would be a data race (as defined by C11) otherwise. > > The implementation of atomic_*() in glibc is an exception to that rule, > in that on some systems we may know that in a controlled environment > (eg, function not inlined or volatile used), the compiler will generate > code for a plain store/load in the implementation of an atomic_*() > function that is equivalent to a relaxed MO atomic store/load (including > effects of fences). > This makes concurrent relaxed MO loads/stores work. > > If we also have a non-multi-core system, entering the kernel emulation > for CAS then stops all other execution on the system, so the CAS > emulation in the kernel is atomic. > If instead we have a multi-core system, either the kernel would have to > temporarily stop all other cores while emulating the CAS, or all > atomic_*() would have to use the kernel. Which of these two options is > better is hard to say upfront. Agreed. For hppa we have similar problems we I'm moving everything over to emulated CAS from initialization to accesses e.g. atomic_exchange_*. -- Cheers, Carlos.