Date: Mon, 3 Jun 2013 22:15:59 +0200 From: Ed Schouten <ed@80386.nl> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-mips@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Kernelspace C11 atomics for MIPS Message-ID: <CAJOYFBBTYtUSWPthj96Ga6aoPFwmG4PUSrZ_ir0nE=46o-tb1g@mail.gmail.com> In-Reply-To: <D02AF210-5129-40AB-9481-3F0A44575E98@bsdimp.com> References: <CAJOYFBD502MYbkVR2hnVDTYWOvOUr15=OPyjotNvv%2BZ09vQ1OQ@mail.gmail.com> <D02AF210-5129-40AB-9481-3F0A44575E98@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <imp@bsdimp.com>: > 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 <machine/atomic.h>. 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 <ed@80386.nl>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJOYFBBTYtUSWPthj96Ga6aoPFwmG4PUSrZ_ir0nE=46o-tb1g>