From owner-freebsd-arch@FreeBSD.ORG Mon Jun 3 20:16:00 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2E47FFA; Mon, 3 Jun 2013 20:16:00 +0000 (UTC) (envelope-from edschouten@gmail.com) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by mx1.freebsd.org (Postfix) with ESMTP id CFDC91368; Mon, 3 Jun 2013 20:15:59 +0000 (UTC) Received: by mail-ve0-f176.google.com with SMTP id c13so3133867vea.7 for ; Mon, 03 Jun 2013 13:15:59 -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=epO2QtREq85Qirwj2jzCOL7EyD4dKSnfZsna/f1A2Y4=; b=YeX3NKgJ1qIhGHuQRp0KfESFzmdD2puMnlPCvs9E5M9yawAO+yH1kYeJ/ulEayyEdS m4LsNbphuwT+oJGwdyCOc7EQ01W+RJReGApnLRQ1p/nGnLGgPFu6MEoCV9wYLEH0Y5Rs NISPaMrZCYMtRlrBdnKaKO6xVAw9DDMeERxkDYYhihRJi6AaRghF/6lyzGKh7rc4FQZS zJYjQCGWBmuBBH7nGFMTi7YPXUK5skC+8rDwEshjwKvQX9kB42f99XI70WJJxVcpApD+ Me2ozlt6VGuSbw+U69dxdhPxM3jTT9fhVrMswYPRRYI6dAw0mhzWLw2oXniy4ubno8BG XwwA== MIME-Version: 1.0 X-Received: by 10.52.183.170 with SMTP id en10mr14965864vdc.5.1370290559285; Mon, 03 Jun 2013 13:15:59 -0700 (PDT) Sender: edschouten@gmail.com Received: by 10.220.107.139 with HTTP; Mon, 3 Jun 2013 13:15:59 -0700 (PDT) In-Reply-To: References: Date: Mon, 3 Jun 2013 22:15:59 +0200 X-Google-Sender-Auth: FeVDz4OIqufmn0UG2b3qrapNfk0 Message-ID: Subject: Re: Kernelspace C11 atomics for MIPS From: Ed Schouten To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: 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: Mon, 03 Jun 2013 20:16:00 -0000 Hey Warner, After playing around a bit I managed to get qemu user mode emulation for mips64 working on my workstation. Apart from a stupid thinko (__sync_fetch_and_sub() did B - A instead of A - B), the code managed to survive the following test, which calls the stdatomic library functions with random parameters: http://80386.nl/pub/stdatomic-fuzzer.txt I'll see if I can push this tool into the tree after polishing it up a bit. Unfortunately it only tests the logical aspects of the routines -- not whether the routines are actually atomic. 2013/6/3 Warner Losh : > 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. I have to confess, that's exactly the part I know very little about. The code I wrote is largely based on the code in . The mips_sync() function has been copied over almost literally. I think tuning this could be done separately. Regarding calling mips_sync() before and after. I think we always have to call it before we perform the action (for example if the atomic call is used to implement an unlock). But indeed, afterwards makes little sense. We would only need to perform a barrier at the compiler level -- not the memory level. It wouldn't make sense to add this explicitly, because these are separate functions in a separate compilation unit anyway. Thoughts? > I have some cavium gear I can easily test on, and some other stuff I can = less-easily test on. Awesome! At least testing it on Cavium would be nice. I've updated the diff. Please refresh. http://80386.nl/pub/mips-stdatomic.txt One easy way to test this, would be to link the fuzzer source file against the stdatomic.c file added by my patch and run that. The source file should compile both in user+kernel now. Thanks, -- Ed Schouten