Re: About gcc builtin atomics
On Tue, 26 Jun 2012 18:14:39 +0000 (UTC), Thorsten Glaser <tg@mirbsd.de> wrote:
> Mikael Pettersson dixit:
>
> >- having a vsyscall page at a fixed location (vdso is too horrible), and
> >- updating a long word in it in each switch_to()
>
> sounds ok to me
>
> >- SMP is initially prohibited, the get_thread_area entry needs to be a
> > proper function, so that a future SMP-capable system can be allowed,
>
> Do we need *MP on m68k at all?
Depends on your perspective. I know commonly available HW isn't SMP,
but the architecture is SMP-capable, there have been some MP machines
(DIAB produced some with 030 and 040, and I've seen VMEbus boards with
dual 040 or 060). And a dual or quad core m68k for an FPGA should
be doable given that both single-core m68k and multi-core non-m68k
FPGAs already exist.
I'm not suggesting that SMP HW will be available any time soon,
but I'd rather keep the option open than design an ABI that cannot
work at all in such a system. The get_thread_area vsyscall would
still be orders of magnitude faster than the current syscall.
> >I could probably implement something like that, but I'm not sure how
> >the kernel maintainers would feel about a per-process vsyscall page...
>
> Not a kernel maintainer, but isn't that the whole point, to have the
> page per-process so no kernel mode round-trips are required?
Yes, but there's also a cost in that there's one more store on every
context switch, and every page table must have one additional entry.
Security-centric people dislike vsyscall pages and prefer vdsos
since their address-space placements can be randomized, but that
also makes vdsos slower to access.
/Mikael
Reply to: