From owner-freebsd-arch@FreeBSD.ORG Tue Jun 4 02:45:50 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5F1F2E25; Tue, 4 Jun 2013 02:45:50 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id 0EB2A13BF; Tue, 4 Jun 2013 02:45:49 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id e1so2570765qcy.8 for ; Mon, 03 Jun 2013 19:45:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bnGVtp2/EgnS27TtyDbKsZ87JYvZoL8p61vYDb7erdA=; b=Hf5pBfMTlR4UlJsOlMuWk3cuYUfFaGBoMd9thKut04fmfqvUvJoTQBlPorQcuxzm5u yBBm7uol/quWIH50jxHXcAOk5KSRCE2tPbXiWKMLt6x/vHLoo2OTcRU3WJSItbM/7edG D0K9RH/ITfZG1AhrOcenss6vnLwshrW84Ki6WNKvH3lWtdjeYjMZC46VGIdSDH9vOqrN 7fbGIF0Ozd78M20cMEO2RaOCr9B4zLkxs6l6zFJc2DxMLY9wzW/W7mBpCy79ADGGg9Hi giq/9S+RL4DmnnymScFWOZj+eGPGz3jlYkRTfQZrxqikmm+s3ovCchMAN03dZ/c+aExV vy4Q== MIME-Version: 1.0 X-Received: by 10.49.38.169 with SMTP id h9mr24294063qek.54.1370313948960; Mon, 03 Jun 2013 19:45:48 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.71.12 with HTTP; Mon, 3 Jun 2013 19:45:48 -0700 (PDT) In-Reply-To: References: Date: Mon, 3 Jun 2013 19:45:48 -0700 X-Google-Sender-Auth: kt6s0ZfAuLunSnQESDzNm8hulqU Message-ID: Subject: Re: Kernelspace C11 atomics for MIPS From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ed Schouten , freebsd-mips@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 02:45:50 -0000 Speaking of this; any idea why the SYNC operators have 8 NOPs following the= m? I noticed that when going through disassemblies of various mips24k .o files= . Adrian On 3 June 2013 10:53, Warner Losh wrote: > > On Jun 3, 2013, at 8:04 AM, Ed Schouten wrote: > >> Hi, >> >> As of r251230, it should be possible to use C11 atomics in >> kernelspace, by including ! Even when not using Clang >> (but GCC 4.2), it is possible to use quite a large portion of the API. >> A couple of limitations: >> >> - The memory order argument is simply ignored, making all the calls do >> a full memory barrier. >> - At least Clang allows you to do arithmetic on C11 atomics directly >> (e.g. "a +=3D 5" =3D=3D "atomic_fetch_add(&a, 5)"), which is of course n= ot >> possible to mimick. >> - The atomic functions only work on 1,2,4,8-byte types, which is >> probably a good thing. >> >> Amazingly, it turns out that it most of the architectures, with the >> exception of ARM and MIPS. To make MIPS work, we need to implement >> some of the __sync_* functions that are described here: >> >> http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html >> >> Some time ago I already added some of these functions to our >> libcompiler-rt in userspace, to make atomics work there. >> Unfortunately, these functions were quite horribly implemented, as I >> tried to build them on top of , which is far from >> trivial/efficient. It is also restricted to 4 and 8-byte types. That's >> why I thought: why not spend some time learning MIPS assembly and >> write some decent implementations for these functions? >> >> The result: >> >> http://80386.nl/pub/mips-stdatomic.txt > > The number of necessary syncs varies by processor type. There's also newe= r synchronization instructions that make this as efficient as possible for = all mips32r2 and mips64r2-based machines. Older Caviums, at least and maybe= newer ones, also have their own variants. What you have will mostly work f= or the processors we have to support. mips_sync could therefore be better. = Doing it before AND after seems like overkill as well. Since sync is a fair= ly performance killing assembler instruction, how would you feel about allo= wing optimizations? > > This is my biggest single concern about the patch, but it also my current= biggest concern about the MIPS atomic operators in general. > >> For now, please focus on sys/mips/mips/stdatomic.c. It implements all >> the __sync_* functions called by for 1, 2, 4 and 8 byte >> types. There is some testing code in there as well, which can be >> ignored. This code disassembles to the following: >> >> http://80386.nl/pub/mips-stdatomic-disasm.txt >> >> As I don't own a MIPS system myself, I was thinking about tinkering a >> bit with qemu to see whether these functions work properly. My >> questions are: >> >> - Does anyone have any comments on the C code and/or the machine code >> generated? Are there some nifty tricks I can apply to make the machine >> code more efficient that I am unaware o? >> - Is there anyone interested in testing this code a bit more >> thoroughly on physical hardware? >> - Would anyone mind if I committed this to HEAD? > > I have some cavium gear I can easily test on, and some other stuff I can = less-easily test on. > > It wouldn't be horrible to commit to head, but it would affect performanc= e in many places. > > Don't commit the kern/bla.c standard change to conf/files, it looks to be= bogus :) > > Warner > > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org"