From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36698 invoked by alias); 1 Nov 2016 15:27:19 -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 36687 invoked by uid 89); 1 Nov 2016 15:27:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=H*Ad:U*davem, surprises, Oracle, H*F:U*andreas X-HELO: mx6.bahnhof.se X-Spam-Score: 0.666 Message-ID: <5818B434.9040201@gaisler.com> Date: Tue, 01 Nov 2016 15:27:00 -0000 From: Andreas Larsson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Torvald Riegel CC: Adhemerval Zanella , GNU C Library , David Miller , "software@gaisler.com" Subject: Re: Remove sparcv8 support References: <48cdf008-b66a-d411-a07a-5a38595978b9@linaro.org> <5809D90E.1090005@gaisler.com> <1477329945.7146.95.camel@localhost.localdomain> <8224de36-8a30-980c-697b-8e4cae481184@linaro.org> <580F6D5E.6050600@gaisler.com> <5810C1A3.9030504@gaisler.com> <1477564701.7146.186.camel@localhost.localdomain> In-Reply-To: <1477564701.7146.186.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg00029.txt.bz2 On 2016-10-27 12:38, Torvald Riegel wrote: > On Wed, 2016-10-26 at 16:45 +0200, Andreas Larsson wrote: >> On 2016-10-25 16:44, Adhemerval Zanella wrote: >>> >>> >>>> On 25 Oct 2016, at 12:34, Andreas Larsson wrote: >>>> >>>>> On 2016-10-24 19:42, Adhemerval Zanella wrote: >>>>> >>>>> >>>>>> On 24/10/2016 15:25, Torvald Riegel wrote: >>>>>>> On Fri, 2016-10-21 at 10:59 +0200, Andreas Larsson wrote: >>>>>>>> On 2016-10-20 21:47, Adhemerval Zanella wrote: >>>>>>>> The sparcv8 build is broken since GLIBC 2.23 due the new pthread >>>>>>>> barrier implementation [1] and since then there is no thread or >>>>>>>> interest on fixing it (Torvald has suggested some options on >>>>>>>> 2.23 release thread). It won't help with both new pthread rdlock >>>>>>>> and cond implementation, although I would expect that it relies >>>>>>>> on same atomic primitive that was not present for pthread barrier. >>>>>>>> >>>>>>>> AFAIK, recent commercial sparc chips from Oracle all supports >>>>>>>> sparcv9. The only somewhat recent sparc chip with just sparcv8 >>>>>>>> support is LEON4, which I really doubt it cares for glibc support. >>>>>>> >>>>>>> Hi! >>>>>>> >>>>>>> We do care about GLIBC support for many different LEON3 and LEON4 >>>>>>> systems. GLIBC support for sparcv8 is important for us and it is >>>>>>> important for our customers. Both LEON3 and LEON4 are continuously used >>>>>>> in new hardware designs. >>>>>> >>>>>> If you do care about it, it would be nice if you could (help) maintain >>>>>> sparcv8 (e.g., regularly testing most recent glibc on sparcv8, at the >>>>>> very least early during the freeze of each release). This ensures that >>>>>> you won't get surprises such as this one, when nobody else is spending >>>>>> resources on it. >>>>>> >>>>>>> We are not always using the latest version of GLIBC (the latest step we >>>>>>> took was to GLIBC 2.20), so unfortunately we missed this issue. We will >>>>>>> look into what the extent of the missing support is. Any pointers are >>>>>>> most welcome. >>>>>>> >>>>>>> Do you have a link to the suggested options on the 2.23 release thread? >>>>>>> I dug around a bit in the archives, but did not find it. >>>>>>> >>>>>>> (As a side note, most of the recent LEON3 and LEON4 chips have CAS >>>>>>> instruction support, but pure sparcv8 support is of course the baseline.) >>>>>> >>>>>> Yes, the lack of CAS is the major problem I am aware of. If the chips >>>>>> you mention do support CAS, then a patch that adds support for the >>>>>> CAS-based atomic operations in glibc would fix the barrier problem >>>>>> (because the generic barrier should just work). The patch would also >>>>>> have to add configure bits or whatever would be appropriate so that >>>>>> glibc can figure out whether it is supposed to be run on a sparcv8 with >>>>>> or without CAS. >>>>>> >>>>>> What about stopping support for plain sparcv8, and keeping to support >>>>>> sparcv8+CAS provided that we have a (group of) maintainer(s) for the >>>>>> latter that can tend to the minimal responsibilities of an arch >>>>>> maintainer and has the time to do that? >>>>> >>>>> At least the build for sparcv9-linux-gnu with -mcpu=leon3 finishes, >>>>> although I am not sure if it correctly runs on leon processors. >>>>> And I seconded Tovarld's suggestion about stop maintaining plain >>>>> sparcv8 and set sparcv8+CAS as the base supported sparc32. >>>> >>>> I have mixed feelings about this, but it is certainly better than >>>> throwing out sparcv8 outright. >>> >>>>> As pointed out by David Miller, correct support for plain sparcv8 >>>>> could really only be provided with kernel supported. And when >>>>> it lands on kernel side, it should work effortlessly with a >>>>> sparcv8 + cas glibc build. >>>> >>>> What do you mean by "work effortlessly with a sparcv8 + cas glibc >>>> build"? >>> >>> Meaning that even if underlying hardware does not support correct CAS, >>> kernel emulation will provide it and thus a default GLIBC sparc32 build >>> will work regardless. >> >> 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. > > Is there still recent sparcv8 hardware that has no native CAS but > multiple CPU cores? I think we've used the kernel emulation only on > non-multi-core systems so far. There are no LEON3 or LEON4 multiprocessor chips that I am aware of that lacks CAS. I cannot rule out that some customer has instantiated such a design though. Best regards, Andreas Larsson