Date: Tue, 29 Sep 2015 19:23:12 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Ian Lepore <ian@freebsd.org> Cc: freebsd-arm@freebsd.org Subject: Re: Shared page and related goodies for ARMv7 Message-ID: <20150929162312.GJ11284@kib.kiev.ua> In-Reply-To: <1443539982.1224.433.camel@freebsd.org> References: <20150929132332.GH11284@kib.kiev.ua> <1443539982.1224.433.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 29, 2015 at 09:19:42AM -0600, Ian Lepore wrote: > I can't do anything with an inline email patch (my mail client destroys > whitespace). Can you send it as an attachment, or put it somewhere on > freefall or something please? I just committed the .note.GNU-stack bits, reviewed by andrew. This reduces the noise in the patch, the rest is available at https://people.freebsd.org/~kib/misc/arm_sharedpage.1.patch > > There is no difference between armv6 and armv7 in our world. The only > armv6 chip we support is the one used in the original rpi and it has a > 16K 4-way L1 cache which means the page coloring issue disappears and we > can treat it the same as an armv7 chip (different cache ops, but the > caches behave the same). Olivier just told me the same, I already changed the elf_machdep.c patch to enable shared page for ARMv6 and later. > > I just skimmed through the patch quickly and the main thing that jumps > out at me is that what you've done works only on rpi2 and aarch64, > because those are the only platforms that support that timer hardware. > (That means I can't test it, but once I get your patch in a usable form > I can have a shot at implementations for other timers). Cortex A7/A15 and whole ARMv8 is not too bad set of machines for fast gettimeofday() IMO, at least for the first try. I am willing to adjust both approach and code it for wider usefulness. > > It's not clear to me that this scheme can even work on most armv7 > hardware because of the timer hardware involved. I think it would mean > giving userland read access to a whole page worth of IO space and in > some cases there are registers in that range where reads have side > effects whose consequences could be dire (such as pending-interrupt > registers). Yes, if timer counter is on the page shared with other registers, which read side effects are not safe, it cannot be used. But I do not see how such hardware could be useful for any syscall-less implementation of gettimeofday(), except for very imprecise one, where counter is written to the shared page on timer interrupt. I do not think that we want such hack done. On x86, HPET timers have relatively sane design, the registers page can be exported to userspace r/o without consequences. Exporting HPET to userspace even could be useful on Core2 (old) machines where RDTSC is unusable. HPET could be made a test bed for this kind of hardware, but the interest is low and I did not coded neccessary infrastructure as result.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150929162312.GJ11284>