Hi All,
Did anybody tried running vdso_test (under Documentation/vDSO in
kernel 4.1) on an ARM 32 bit system?
When I test it on iMX.7 board (kernel 4.1, ARM 32 bit), I get this:
# ./vdso_test
Could not find __vdso_gettimeofday
When I check more in parse_vdso.c, I found that under vdso_sym
function, sym->st_name is returning 0 for the first time, and next it
returns value 54, then exit and finally vdso_sym returning 0.
So, its not able to parse the gettimeofday symbol from the ELF header.
When I check arch/arm/kernel/vdso.so, the symbol is present.
I even tried for clock_gettime, and even this is also failing.
Note: the same test is working fine on Ubuntu 16.04 (64 bit), when
compiled with both 32 bit and 64 bit version.
Even, the test is working on ARM 64 bit.
If anybody is aware, please let me know if vdso_test is supported on
ARM 32 bit system or not?
Thanks,
Pintu
On Tue, Dec 12, 2017 at 09:49:42PM +0530, Pintu Kumar wrote:
> Hi All,
>
> Did anybody tried running vdso_test (under Documentation/vDSO in
> kernel 4.1) on an ARM 32 bit system?
>
> When I test it on iMX.7 board (kernel 4.1, ARM 32 bit), I get this:
> # ./vdso_test
> Could not find __vdso_gettimeofday
>
> When I check more in parse_vdso.c, I found that under vdso_sym
> function, sym->st_name is returning 0 for the first time, and next it
> returns value 54, then exit and finally vdso_sym returning 0.
> So, its not able to parse the gettimeofday symbol from the ELF header.
> When I check arch/arm/kernel/vdso.so, the symbol is present.
>
> I even tried for clock_gettime, and even this is also failing.
>
> Note: the same test is working fine on Ubuntu 16.04 (64 bit), when
> compiled with both 32 bit and 64 bit version.
> Even, the test is working on ARM 64 bit.
>
> If anybody is aware, please let me know if vdso_test is supported on
> ARM 32 bit system or not?
The vdso time functions are only useful if you have an architected timer.
If you don't have one, the time functions are useless and there's little
point in making them available via the vdso.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
Dear Nathan & Russel,
I have few more question about vdso for arm-32-bit.
I am using iMX7 board to very VDSO gettimeofday timing.
To make kernel/Documentation/vDSO/vdsotest work on this board, I
commented the device tree reading property:
arm,cpu-registers-not-fw-configured , from the :
arch/arm/kernel/vdso.c
[However, I havent removed the property from device-tree itself, so it
is still being read by: drivers/clocksource/arm_arch_timer.c ⇒
arch_timer_of_init(…)]
But it seems the VDSO gettimeofday call is rather very slow.
This is the result of 10 iteration (with 10 seconds delay between
each), after fresh reboot:
bash-3.2# ./run_vdso.sh
The time is 1116.898864
===========================
The time is 1126.957507
===========================
The time is 1136.988507
===========================
The time is 1147.023134
===========================
The time is 1157.053017
===========================
The time is 1167.082912
===========================
The time is 1177.117722
===========================
The time is 1187.150945
===========================
The time is 1197.180820
===========================
The time is 1207.215339
===========================
The time is 1217.245189
===========================
Although architected timer support is not available in firmware, so it
may not give the accurate timing.
1) So, I wonder why vdso call is very slow and increasing by every second ?
This is the result of benchmark test.
bash-3.2# ./vdsotest_bench gettimeofday bench
gettimeofday: syscall: 681 nsec/call
gettimeofday: libc: 4190 nsec/call
gettimeofday: vdso: 4171 nsec/call
Also, when I call gettimeofday API from a sample program, I could not
find any system call trace.
bash-3.2# time ./test-vdso-syscall.out
real 0m3.997s
user 0m3.980s
sys 0m0.000s
2) So, how do I conclude whether VDSO gettimeofday is working correctly or not ?
3) Is it important to have that device-tree property in VDSO, if
arch-timer support is not available in firmware ?
Please let me know your opinion.
Thank You!
Pintu
On Thu, Dec 14, 2017 at 3:51 PM, Russell King - ARM Linux
<[email protected]> wrote:
> On Thu, Dec 14, 2017 at 10:50:50AM +0530, Pintu Kumar wrote:
>> Oh ok. Thanks for this information.
>> So, in conclusion, can I summarize like this: VDSO support on ARM 32-bit
>> 1) VDSO works only on Cortex A7/A15 -> where generic timer extension
>> is available.
>> 2) VDSO works only on kernel 4.1 and above => where 32-bit vdso
>> support is available
>> 3) glibc version should be 2.20 or higher
>> 4) This device-tree property should not be set:
>> arm,cpu-registers-not-fw-configured => This means there is a firmware
>> bug
>>
>> Sorry, but still I have 2 more queries:
>> 1) Which is the firmware that we are talking about here ? What is the
>> name of firmware ? Is it available in kernel ?
>
> It's not in-kernel firmware, but whatever runs on the kernel prior to
> booting the kernel.
>
>> 2) Is there any ARM 32-bit board available, where I can confirm that
>> VDSO works on ARM 32-bit?
>
> I'm know of none. That's not to say that there aren't any, I just don't
> know of any.
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
> According to speedtest.net: 8.21Mbps down 510kbps up
> I commented the device tree reading property:
> arm,cpu-registers-not-fw-configured , from the arch/arm/kernel/vdso.c
Don't do that, please. The presence of that property indicates that the counter is not suitable for use by the OS. There is nothing we can do in Linux to make the VDSO useful on this system; that is why it gets disabled at runtime.
The timing measurements you get are likely tainted by garbage results from the VDSO itself.
On Thu, Feb 8, 2018 at 9:41 PM, Lynch, Nathan <[email protected]> wrote:
>> I commented the device tree reading property:
>> arm,cpu-registers-not-fw-configured , from the arch/arm/kernel/vdso.c
>
> Don't do that, please. The presence of that property indicates that the counter is not suitable for use by the OS. There is nothing we can do in Linux to make the VDSO useful on this system; that is why it gets disabled at runtime.
>
> The timing measurements you get are likely tainted by garbage results from the VDSO itself.
OK thank you for your feedback.
But, we wanted to know, why vdso call timing is very high here. What
does this timing indicates?
gettimeofday: vdso: 4171 nsec/call
1) How to decide whether to enable or disable VDSO in the system, if
its not suitable.
Because in a VDSO enabled system, when we use gettimeofday API, we see
that its not falling back to the systemically, but may rather return a
garbage value from vdso itself.
If that is the case, shall we disable CONFIG_VDSO itself or keep it as it is ?
Please suggest your opinion.
2) Can you list down 1-2 arm 32-bit board, where VDSO can work perfectly ?
This will be really helpful for us to take some decision.
Thank You!
Pintu