From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 083FBC4332F for ; Tue, 8 Nov 2022 05:16:30 +0000 (UTC) Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.96) (envelope-from ) id 1osGy1-0008Ap-1j; Tue, 08 Nov 2022 00:16:09 -0500 Received: from mscreen.etri.re.kr ([129.254.9.16]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (Exim 4.96) (envelope-from ) id 1osGxx-00080t-0T for kernelnewbies@kernelnewbies.org; Tue, 08 Nov 2022 00:16:05 -0500 Received: from unknown (HELO send001-relay.gov-dooray.com) (211.180.235.152) by 129.254.9.16 with ESMTP; 8 Nov 2022 14:15:56 +0900 X-Original-SENDERIP: 211.180.235.152 X-Original-MAILFROM: ckim@etri.re.kr X-Original-RCPTTO: kernelnewbies@kernelnewbies.org Received: from [10.162.225.106] (HELO smtp001-imp.gov-dooray.com) ([10.162.225.106]) by send001-relay.gov-dooray.com with SMTP id 69f42bb06369e60c; Tue, 08 Nov 2022 14:15:56 +0900 DKIM-Signature: a=rsa-sha256; b=i4u3+urv8/v3BtrYVg1hlXwRwtWr+hLVzdNjCanZoUgQPRKWbD+02XWjhGQsuYQnhJ0YS9OPXs 1bNu3vXMDloOFYlSDeUFmQXygG7V42iKNglsBX10pPBykLhvGNCRjggMAc5QAG2M8KiSYlBIloSj AGo1DwQcaZ7f6bvRmfB9ua082BFMHPwKsrf6ObjopwbHcLf9SwXjNAVsfSovqCd0YSZdubVG7HqY vUZE1uIAbx0nTyvEu8+dRqhxGoGlNrbSsIJjb6gxOYKbsmY7uNB7xN832PI4zoW3ccBPJ81XSlEi 1WrWJZuFSbR0DxZEl+90ODgN7E+47O3dL99J/Gvg==; c=relaxed/relaxed; s=selector; d=dooray.com; v=1; bh=J3I+nvQjH2p38jEaJ0ZZd2iF47mqvux+HtKIjn4vlpU=; h=From:To:Subject:Message-ID; Received: from [129.254.132.39] (HELO CHANKIMPC) ([129.254.132.39]) by smtp001-imp.gov-dooray.com with SMTP id 1b955e906369e60c; Tue, 08 Nov 2022 14:15:56 +0900 From: "Chan Kim" To: References: <143801d8f02c$6a126f90$3e374eb0$@etri.re.kr> <5f877928-2e90-6884-70b5-ec5be2cf93b7@siddh.me> <148301d8f10c$39057470$ab105d50$@etri.re.kr> In-Reply-To: <148301d8f10c$39057470$ab105d50$@etri.re.kr> Subject: RE: clock_gettime function doesn't scale to real time.. and changing CNTFRQ_EL0 doesn't make any change..(arm64) Date: Tue, 8 Nov 2022 14:15:55 +0900 Message-ID: <153e01d8f331$2e11dfa0$8a359ee0$@etri.re.kr> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Content-Language: ko Thread-Index: AQHcXHfdwGpfNS4bc4V5ltsQFFSRlwIJ2w5TAYD+JD+uEU9+kA== Cc: 'Siddh Raman Pant' , 'Linus Probert' X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kernelnewbies-bounces@kernelnewbies.org Hello all, I fixed this problem and now the time measurement and commands like sleep works just fine. Two points I fixed : - I had 'clock-frequency' property set with wrong frequency in my timer node in the device tree so I removed it. The document says when the boot loader sets CNTFRQ register correctly, we don't have to provide 'clock-frequency' property value. - The correct frequency of the system counter (arm464) was 10MHz in our board. Previously I set CNTFRQ register with 5MHz but I fixed it to 10MHz. One more thing to note. The system counter has both system register view and memory mapped register view. Previously I said even if I set cntfrq_el0 register with some values (using system register, "msr cntfrq_el0, COUNTER_FREQUENCY") it did not change anything. It was because I set the same register with old value (5MHz) using the memory mapped access later (like with "writel(COUNTER_FREQUENCY, 0x4c018020);"). Hope this helps someone later. Thank you! Chan Kim >-----Original Message----- >From: Chan Kim >Sent: Saturday, November 5, 2022 8:46 PM >To: 'Siddh Raman Pant' >Cc: 'Kernel Newbies' >Subject: RE: clock_gettime function doesn't scale to real time.. and >changing CNTFRQ_EL0 doesn't make any change..(arm64) > >Hi,Siddh and Linus, > >I tried using 'time' command to measure the time and my program output is >the same in commercial intel machine (ubuntu 20.04). >... >fib(041) = 165580141 >fib(042) = 267914296 >fibonacci finishing... >Execution time : 3.801840 sec > >real 0m3.806s >user 0m3.802s >sys 0m0.005s > >So it looks like the application program doesn't have problem. >In the program exec_time_nsec is actually in unit of second. Because >tv_nsec is in unit of nsec, I'm converting it to second by dividing it with >BILLION. >And yes, the CNTFRQ_EL0 is for software use. Hardware just runs with clock >and it know only the number of clocks and doesn't know 1000000 clock period >physically represents what seconds. CNTFRQ_EL0 is letting the software able >to convert the number of clocks to physical time. >I'm at home now and can't do experiment with the board now. I'll try >following the pc_clock_gettime function as you showed to see how it works. > >Thanks for the advices. >Chan Kim > >>-----Original Message----- >>From: Siddh Raman Pant >>Sent: Saturday, November 5, 2022 4:51 AM >>To: Chan Kim >>Cc: Kernel Newbies >>Subject: Re: clock_gettime function doesn't scale to real time.. and >>changing CNTFRQ_EL0 doesn't make any change..(arm64) >> >>On Fri, 04 Nov 2022 14:34:15 +0530, Chan Kim wrote: >>> Hello linux experts and newbies, >>> >>> I have ported linux on our arm64 fpga board. Both 5.10.0 and 5.15.xx >>> works ok with minimal config. >>> >>> I have run a simple application and timed the processing time using >>> clock_gettime function. >>> >>> It felt like it took almost 2.3 seconds but the program say it took >>> only >>> 0.36 seconds. >> >>Try a simple command line loop to see if the problem is with system or >>your >>program: while $(sleep 1); do echo "Hi"; done; >> >>Also, while of no concern here, note that kernel also has a real-time >>config (CONFIG_PREEMPT_RT). >> >>> Here is how I did it in the application. >>> >>> Int main() { >>> struct timespec start, stop; >>> float exec_time_sec, exec_time_nsec; >>> >>> //check start time >>> if (clock_gettime(CLOCK_REALTIME, &start) == -1 ) { >>> perror ("clock_gettime"); >>> exit(EXIT_FAILURE); >>> } >>> >>> Do something... (calculate fibonacci value for 1 ~ 30) >>> >>> //check end time >>> if (clock_gettime(CLOCK_REALTIME, &stop) == -1 ) { >>> perror ("clock_gettime"); >>> exit(EXIT_FAILURE); >>> } >>> >>> //Normalize to mili second >>> exec_time_sec = (float)(stop.tv_sec - start.tv_sec); >>> exec_time_nsec = (float)((double)(stop.tv_nsec - >>start.tv_nsec)/(double)BILLION); >>> printf("Execution time : %f sec\n", exec_time_sec + exec_time_nsec); >>> >>> return 0; >>> >>> } >> >>Adding to what Linus said in the other reply, CLOCK_REALTIME is not >>guaranteed to be monotonic. For calculation of intervals, you should >>instead use CLOCK_MONOTONIC or CLOCK_MONOTONIC_RAW. >> >>Also, try just having Fibonacci calculation in main, and then use the >>`time` command to achieve what you want. >> >>> I used u-boot program for loading linux kernel and the u-boot program >>> sets the CNTFRQ_EL0 register with 5000000. >>> >>> (which is 5MHz, I heard the system clock runs at 5MHz in the board). >>> >>> The description of the register in armv8 arch manual says : >>> > This register is provided so that software can discover the >>> > frequency of the system counter. It must be programmed with this >>> > value as part of system initialization. The value of the register >>> > is >>not interpreted by hardware. >>> >>> I tried setting the CNTFRQ_EL0 with 20Mhz, expecting the execution to >>> be displayed 4 times shorter but it is the same! >> >>Because as the description says, this register is not interpreted by >>the hardware. That means this won't affect hardware in any way, and >>thus won't increase frequency. That's why your execution time remains the >same. >> >>The value stored here is for use by software to know the clock >>frequency of the machine, so it can do its time related calculations >appropriately. >> >>What you did is equivalent of trying to hoodwink the system! >> >>> I couldn't find how linux uses clock_gettime. >> >>If you mean how clock_gettime function is defined, see it here: >>https://elixir.bootlin.com/linux/latest/source/kernel/time/posix- >>clock.c#L259 >> >>Otherwise: man clock_gettime >> >>> How can I solve this problem? >>> Any advice will be deeply appreciated. >> >>Try making the changes and let us know. This is new for me too! >> >>> Thank you! >>> Chan Kim >> >>Please use plain text email instead of HTML, that's the kernel mailing >>list etiquette. It is also superior once you get the hang of it! :) >> >>Thanks, >>Siddh > > > > > >_______________________________________________ >Kernelnewbies mailing list >Kernelnewbies@kernelnewbies.org >https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies