Thread (22 messages) flat view 22 messages, 6 authors, 2014-09-26

[PATCH v2 0/3] arm_arch_timer: VDSO preparation, code consolidation

From: Russell King - ARM Linux <hidden>
Date: 2014-09-24 15:08:34
Also in: lkml

On Wed, Sep 24, 2014 at 04:04:09PM +0100, Catalin Marinas wrote:
On Wed, Sep 24, 2014 at 03:52:57PM +0100, Russell King - ARM Linux wrote:
quoted
I'm *not* arguing against having a VDSO to speed up that crap.  What
I'm trying to get to the bottom of - something which has been totally
lost sight of - is what the friggin effect of this stuff is on CPUs
*without* the architected timer.

Until I get an answer to what the measured effect is, I'm saying no to
VDSO on ARM, because - as seems to be the norm - the evaluation job is
only half done.
I agree.

If there is an overhead (possibly), I think it can be solved in software
maybe by having two VDSO images, one with gettimeofday and one without.
If it's only gettimeofday in VDSO (and signal return still via the
vectors page), we could just avoid inserting it into the user address
space when arch timers aren't present.
The signal handling is no longer in the vectors page (it hasn't been for
over a year now), it is in a separate page which is mapped randomly.
These VDSO patches change it to place it along side the VDSO pages.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help