From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9610 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 23:43:29 -0400 Message-ID: <20160314034329.GK9349@brightrain.aerifal.cx> References: <20160313002140.GG9349@brightrain.aerifal.cx> <20160314021357.GJ9349@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 1457927025 20710 80.91.229.3 (14 Mar 2016 03:43:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Mar 2016 03:43:45 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9623-gllmg-musl=m.gmane.org@lists.openwall.com Mon Mar 14 04:43:45 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 1afJQ1-0003jg-0S for gllmg-musl@m.gmane.org; Mon, 14 Mar 2016 04:43:45 +0100 Original-Received: (qmail 7391 invoked by uid 550); 14 Mar 2016 03:43:42 -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 7373 invoked from network); 14 Mar 2016 03:43:41 -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:9610 Archived-At: On Mon, Mar 14, 2016 at 11:55:15AM +0900, Masanori Ogino wrote: > 2016-03-14 11:13 GMT+09:00 Rich Felker : > > 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. > > Well, it seems that I don't really understand vDSO. The way vdso works is that the kernel contains an image of a small ELF shared library file, and maps it into the virtual address space of each user process, and exposes its address as part of the "aux vector" that the dynamic linker or main program entry point receives and can process. While anything could be included in the vdso, normally what the kernel puts there are functions that allow userspace to bypass actually making a system call for some things that _can_ be done without a system call (no need for kernel privs) but where the _way_ to do them is only known by the kernel (e.g. hardware model specific, or dependent on memory structures the kernel writes and exposes to userspace but does not guarantee stability for). Some examples are time/gettimeofday/clock_gettime, getcpu, etc. If userspace chooses to use the vdso, it does symbol lookups in it using the same mechanisms used for dynamic library symbol lookup, then calls the resulting function instead of making a syscall. > My current understanding is, vDSO make it possible that: > > 1. programs targeting without-A processors use syscalls on without-A > processors, and > 2. the programs use atomic instructions on with-A processors. (no > interruption, no context switching!) > (3. programs targeting with-A processors runs normally, without > calling such vDSO function) > > Is it correct? If so, it would be really nice. Even better. Indeed, a baseline vdso-based compare-and-swap for riscv would look like your above items 1 and 2, and item 3 if you build binaries that depend on a processor with the "A" option. But in the future, for non-SMP setups, case 1 could be replaced with a scheduler-based restart approach like pre-v6 ARM and SH3/SH4 use, yielding a huge performance boost (maybe around 100x speedup in locking/atomics). The way this works is that, when resuming a task that was preempted, the scheduler just has to check if the program counter is in the cas function in the vdso. If so, it resets the program counter to the start of that function before resuming userspace. At one point there was a good article on how the ARM implementation of this works, but I can't find it right now. Rich