Received: by 10.223.176.5 with SMTP id f5csp1567093wra; Wed, 7 Feb 2018 23:11:32 -0800 (PST) X-Google-Smtp-Source: AH8x227CTeiGgGZOYahhVMxj8yGxtcWIF5oeFrmmRWVc+jkQmNfuwZMNYU7dZ2SI6xq7va7pVHWV X-Received: by 2002:a17:902:9898:: with SMTP id s24-v6mr8834034plp.275.1518073892078; Wed, 07 Feb 2018 23:11:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518073892; cv=none; d=google.com; s=arc-20160816; b=JEzUriyWLWtwDM1K+f3TvYON/5noaeM4WnA6hvFk4HnRDT+nUwOJ4VqcgWdEx876jf GYUqy5Vu2nZ5H8CccK/GH6Dfsw9OPHpAHhVkG7LTljkV7vpPejOy8Q6LkPDGpe9l2RLA SEflonfBNkiiCAHgpvlkF8cfYy7Tp73WemSquRtGhXAwKU6p56NdzYR5671NAO8iEWeW LVTnhiifrkwkkEcThmHeIcoy8PqZ3CqgrIYlyFqgrLGZcE5RcxZNNwsPHMkIppCQknoX F8erHsAdj695Rlmx+EWG3SWsNVd2vV9KBMdK4F3xDx34jzu5RuK+dCsp0HP7CHekGD2l f71w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:to:subject :message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=Ou5VRieqeGoi/A+NwHb101GRzVvPX9GLNM0J3dVAXMw=; b=xVENV7xJWBnQaFjZlhicQhwN4MfUbylkIo7dNyUojmJBZSLLS7Cd2TdGJcsHQzBpu2 VDaB/p0/HH+e/sgtvGLn5JbymuBhrHVxVemDvNGpwsyXfLNcvtLtwucQKo8AaIegds/h M1gcR2NrYzQ7Ylc+FeGyvUCKfuSqMMGoUGyYQPUM7mHD8pwVaOU7Q9SZuJywzQQHOrk3 XLrgVV1OCzAVwJxbY7dCiIddPyVhhhDEivaRKc1rZ2Bwm7LMjQqErXKH0JHs4R8P6eOK PLwJ9GRgnwBivbIrMhZL4m2/x3gWKClr3uYVkqWIqubmoIVIrs4kvnstq0p2fDn/2W0U tHNg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=UQjItESf; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f4si1561624pgp.421.2018.02.07.23.11.18; Wed, 07 Feb 2018 23:11:32 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=UQjItESf; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751310AbeBHHKa (ORCPT + 99 others); Thu, 8 Feb 2018 02:10:30 -0500 Received: from mail-vk0-f66.google.com ([209.85.213.66]:46322 "EHLO mail-vk0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751055AbeBHHK2 (ORCPT ); Thu, 8 Feb 2018 02:10:28 -0500 Received: by mail-vk0-f66.google.com with SMTP id e125so2150169vkh.13 for ; Wed, 07 Feb 2018 23:10:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=Ou5VRieqeGoi/A+NwHb101GRzVvPX9GLNM0J3dVAXMw=; b=UQjItESfgPaxry6giCrehEvMMthW0cWPJxExiPmoNogqy+1Xfsq3pvw685iRUns9tW 0Y5GORoEmiXxducWjeqkfGyKnHAMqcIyn+xNh20/F0kWjPPV2lKOsESB/ANm4o4MR7Wx H6gCif4GK7fdNjRdYHljY723NHmKrPDnRk7xPRXQ6u/jNgd1FmzIebaQ76bx+TelaFaV AEsB+UFdCA9EbcZpkqQryxD5DNX39uBXVotS+036t84JIcrtdkI/SdcFpJ/8GBiI5sNv 29UKXl8YjhVHkx0sVIAomObRu58eRN3x856mBJDJ9xSnxboXyln/UQjUzkFwmZzMLueV qDSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=Ou5VRieqeGoi/A+NwHb101GRzVvPX9GLNM0J3dVAXMw=; b=J/n3xVv36c1AX9E0IOXOvqGUkJUzxQvwC8VEG1JDICySrA2+/YeTDZY7+Xy2qevdHI ISdRZCuJWyubQ3WbmC69npcmkz4+6GJLE6lotNRx/VV01Dt19UUI3l75+RB76O8YJiAJ 1gO92cqln2tK6NAo94I85OKH7k3fcN3KSGjMpq40KmkFZ/H1WDrgDzLsUw+LEXOfbVt5 PNT0FRCECImBka5MG9DMuPR+dQwkn6cjE5Dv2Ztax+iVfZVXkzv/xEO6ZNFXEAJ4lvIt ekCg0706zr7r84Y2nSY4qLw1UcgZyAf/sMiELQXxXKads+IaUHIFWgg+I/kSQDOnhyIq cVsQ== X-Gm-Message-State: APf1xPDafyST+iNKqjAGPMuVDNqz88298eW+g0mAc5iDoZfxxD+BQmza IwdvhD7nC6kawwjQIhOxUGrOyCXvAtCbTCxr+k78eQ== X-Received: by 10.31.164.69 with SMTP id n66mr6919263vke.49.1518073827402; Wed, 07 Feb 2018 23:10:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.85.216 with HTTP; Wed, 7 Feb 2018 23:10:26 -0800 (PST) In-Reply-To: <20171214102148.GO10595@n2100.armlinux.org.uk> References: <20171212162612.GB10595@n2100.armlinux.org.uk> <1513098352501.51185@mentor.com> <20171212172034.GC10595@n2100.armlinux.org.uk> <20171213111718.GJ10595@n2100.armlinux.org.uk> <20171213171530.GM10595@n2100.armlinux.org.uk> <1513186632784.96495@mentor.com> <20171213173956.GN10595@n2100.armlinux.org.uk> <20171214102148.GO10595@n2100.armlinux.org.uk> From: Pintu Kumar Date: Thu, 8 Feb 2018 12:40:26 +0530 Message-ID: Subject: Re: [VDSO]: vdso_test failing on arm 32 bit To: Russell King - ARM Linux , "Lynch, Nathan" , open list , david.brown@linaro.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 =E2=87=92 arch_timer_of_init(=E2=80=A6)] 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D The time is 1126.957507 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D The time is 1136.988507 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D The time is 1147.023134 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D The time is 1157.053017 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D The time is 1167.082912 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D The time is 1177.117722 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D The time is 1187.150945 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D The time is 1197.180820 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D The time is 1207.215339 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D The time is 1217.245189 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D 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 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 =3D> 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 =3D> 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