From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9611 Path: news.gmane.org!not-for-mail From: Masanori Ogino Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl without atomic instructions? Date: Mon, 14 Mar 2016 13:24:11 +0900 Message-ID: References: <20160313002140.GG9349@brightrain.aerifal.cx> <20160314021357.GJ9349@brightrain.aerifal.cx> <20160314034329.GK9349@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1457929511 20841 80.91.229.3 (14 Mar 2016 04:25:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Mar 2016 04:25:11 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9624-gllmg-musl=m.gmane.org@lists.openwall.com Mon Mar 14 05:25:11 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 1afK46-0002Li-FR for gllmg-musl@m.gmane.org; Mon, 14 Mar 2016 05:25:10 +0100 Original-Received: (qmail 21929 invoked by uid 550); 14 Mar 2016 04:24:24 -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 21864 invoked from network); 14 Mar 2016 04:24:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to; bh=mcUvMYyojYU6JBL57PsyXf6vp3XbAQjbK20+Zpu+lfQ=; b=oni94i3+ZvIfBwnnvYLV+hh5867jxtktqNfHGL9jh5+OvbTBBjpFjsjo3YpCzgYESP eGhFFoKpVg1yMm8/0NQi4PGre2QI6Xlt1d7EGd+r3jrM9W+QhJkUvId6OEY+KpeX57Uw aCm5v5UvQY/hA2Ta6UnrItRe30UYFUCZOYOI4KYKWoUcnT0UxVncTjOnE0EWBiCjygwA +jp/EOYS83hfwClmq3Vjd7uPDMZduk0RXWWDdRQIvgwh7UhHfb6yjL4WrEjCL2pOpPgN wAGp386tPuMRccddJrS6s/U5UCWkz2lUPyOOEPwHEUK0ybC4BSzQfGTwT4ZWHVmfQ5vh nGJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to; bh=mcUvMYyojYU6JBL57PsyXf6vp3XbAQjbK20+Zpu+lfQ=; b=D56mVaLAbX+q9VWK0A+UnP+t9B0X3WV/TkedO+hKf/olNvWX6epFmCnnRPRWN44a74 sO4PJkZKmXa0YCshvfP5/tNyguPSQCRYg8OdpMPJP89l4tYIFuj2pMqZ2THaRfXiUcFk pLb4r2nioT56Erk/e1ye1jaNWtHuYaUyKJcdaK1ScxRmDTsNnP9Vn1pka0/sjykJKnbK UmOkLM8QkloSrOiGWXTiuRA3Zra/pC29biW09qArNm6lN2P800BY1F4aJgPKcl9XAK0r okkL4bEJGba/UGzWVwF6Pi81wn1MmY2lovDrGq+LgueiH9lLMaD9fBe2WF/kNs6EcpZ5 LPgg== X-Gm-Message-State: AD7BkJJ1+fjgtaT/NwK3Y3zp46vAik0UaHpU6+qHnqlPAmJ2uGveJglpBHH+4AtChRhvdHoqliRggJetAdl84Q== X-Received: by 10.202.173.146 with SMTP id w140mr12245726oie.118.1457929451661; Sun, 13 Mar 2016 21:24:11 -0700 (PDT) Original-Sender: masanoriogino@gmail.com In-Reply-To: <20160314034329.GK9349@brightrain.aerifal.cx> X-Google-Sender-Auth: 0isW3AP9y1It9VeAo2gXWnfkpb8 Xref: news.gmane.org gmane.linux.lib.musl.general:9611 Archived-At: 2016-03-14 12:43 GMT+09:00 Rich Felker : > On Mon, Mar 14, 2016 at 11:55:15AM +0900, Masanori Ogino wrote: >> 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. OK, it is getting clear to me now. Thank you. >> 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. Fantastic! I will append this to the work list. It is really worthwhile to work on. -- Masanori Ogino