From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: musl without atomic instructions?
Date: Sun, 13 Mar 2016 22:13:57 -0400 [thread overview]
Message-ID: <20160314021357.GJ9349@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAA-4+jdyVVp-dW5KWsn0dhh_hCDrMM21T9fyKeaTijVTRk7H5Q@mail.gmail.com>
On Mon, Mar 14, 2016 at 10:34:22AM +0900, Masanori Ogino wrote:
> 2016-03-13 9:54 GMT+09:00 Masanori Ogino <masanori.ogino@gmail.com>:
> > 2016-03-13 9:21 GMT+09:00 Rich Felker <dalias@libc.org>:
> >> 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
next prev parent reply other threads:[~2016-03-14 2:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-12 23:47 Masanori Ogino
2016-03-13 0:21 ` Rich Felker
2016-03-13 0:54 ` Masanori Ogino
2016-03-14 1:34 ` Masanori Ogino
2016-03-14 2:13 ` Rich Felker [this message]
2016-03-14 2:55 ` Masanori Ogino
2016-03-14 3:43 ` Rich Felker
2016-03-14 4:24 ` Masanori Ogino
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160314021357.GJ9349@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).