From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9608 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl without atomic instructions? Date: Sun, 13 Mar 2016 22:13:57 -0400 Message-ID: <20160314021357.GJ9349@brightrain.aerifal.cx> References: <20160313002140.GG9349@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1457921660 10890 80.91.229.3 (14 Mar 2016 02:14:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Mar 2016 02:14:20 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9621-gllmg-musl=m.gmane.org@lists.openwall.com Mon Mar 14 03:14:19 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1afI1O-0008O1-AH for gllmg-musl@m.gmane.org; Mon, 14 Mar 2016 03:14:14 +0100 Original-Received: (qmail 28545 invoked by uid 550); 14 Mar 2016 02:14:11 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 28504 invoked from network); 14 Mar 2016 02:14:10 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9608 Archived-At: On Mon, Mar 14, 2016 at 10:34:22AM +0900, Masanori Ogino wrote: > 2016-03-13 9:54 GMT+09:00 Masanori Ogino : > > 2016-03-13 9:21 GMT+09:00 Rich Felker : > >> Minimal profiles for microcontroller use lack it (this was a > >> mistake in the riscv ISA specification, IMO), so if supporting these > >> ISA levels is interesting, there are at least three options: > >> > >> 1. Have the kernel trap the unimplemented instructions and emulate > >> them. > >> > >> 2. Have userspace issue a system call to have the kernel mediate > >> atomic accesses. > >> > >> 3. Integrate atomic sequence restart with the scheduler: at scheduling > >> time, the kernel determines if the task being resumed was > >> interrupted in the middle of a sequence of instructions that's > >> supposed to be atomic, and if so, resets the program counter to the > >> beginning of the sequence. (This is how pre-v6 ARM and most SH > >> models work.) > >> > >> Option 3 offers by far the best performance but inherently only works > >> on uniprocessor. Options 1 and 2 could theoretically support SMP as > >> long as the kernel has some other way of ensuring mutual exclusion and > >> memory synchronization between the processors. > >> > >> Of course the best of all worlds is to have the kernel provide a vdso > >> function for atomic cas which it can then provide an optimal > >> implementation of for the particular processor being used. Then > >> baseline-ISA-level riscv binaries would use the vdso, and ones > >> targeting an ISA level that's known to have native atomic instructions > >> would use the inline instructions. > > > > OK, I will ask about the current status on the RISC-V sw-dev ML. > > On sw-dev, Darius Rad taught me that there is a syscall to perform CAS > on RISC-V without the A standard extension. CONFIG_RV_SYSRISCV_ATOMIC > enables it (with RISC-V patches.) > > For reference, the source code is here: > https://github.com/riscv/riscv-linux/blob/master/arch/riscv/kernel/sys_riscv.c IMO a vdso function should be added that makes the syscall, rather than having libc call the syscall directly; this would allow the kernel to automatically provide a better implementation in the future without the need to rebuild applications. Using a syscall for this is very slow. Working with kernel people to propose such a thing (or even implementing it and submitting kernel patches) is certainly one option for something to add to a GSoC project proposal to make it more substantial. Rich