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: > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
