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 0C214C433FE for ; Tue, 8 Nov 2022 05:18:55 +0000 (UTC) Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.96) (envelope-from ) id 1osH0d-0000nl-3A; Tue, 08 Nov 2022 00:18:51 -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 1osH0a-0000nV-2O for kernelnewbies@kernelnewbies.org; Tue, 08 Nov 2022 00:18:49 -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:18:45 +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.112] (HELO smtp002-imp.gov-dooray.com) ([10.162.225.112]) by send001-relay.gov-dooray.com with SMTP id 414d9edf6369e6b5; Tue, 08 Nov 2022 14:18:45 +0900 DKIM-Signature: a=rsa-sha256; b=o6d1/uxJ2DYR8H4/YyFxyPMsgxq2gOsWAFONG7TZGQJmEYC2s/wr4jx0K0QqicvwhaVQO/NFxA QLBMPlSNaaBeAo3f4MK4Hwi7tRrAw2U5IMIIxFs52NErPjvXcxrRAkS14Xe4K4ATYnbhH3Ehni21 ZNEXeJmFRxYOQOrS6TaxflqnOPAR3AASs5a4Z7+cTPw92iFhj3iI/OTPuIYlrBDYRPwlsNmjGk/T 9fwwbTAvDazrvQsRldiXrNTqfCwyGV1Bl7ZUhzWfO9ILvIMmgs2Qu66yTPpfHsihgq4+L+WURPBn Xl9kDkmsMTVYuLF66u9U7TtRuFYvqvf9XQVjchmA==; c=relaxed/relaxed; s=selector; d=dooray.com; v=1; bh=YConyeeAGQ8SMP8v3godsf8nWIRfedS0Up89BVF+ef4=; h=From:To:Subject:Message-ID; Received: from [129.254.132.39] (HELO CHANKIMPC) ([129.254.132.39]) by smtp002-imp.gov-dooray.com with SMTP id ede392b36369e6b5; Tue, 08 Nov 2022 14:18:45 +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: 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:18:44 +0900 Message-ID: <154001d8f331$92b8eed0$b82acc70$@etri.re.kr> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Content-Language: ko Thread-Index: AQHcXHfdwGpfNS4bc4V5ltsQFFSRlwIJ2w5TAYD+JD8CkRy86q38yixQ 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 There is a typo : Setting cntfrq_el0 is done by " msr cntfrq_el0, x0 " in the code. >-----Original Message----- >From: Chan Kim >Sent: Tuesday, November 8, 2022 2:16 PM >To: 'kernelnewbies@kernelnewbies.org' >Cc: 'Siddh Raman Pant' ; 'Linus Probert' > >Subject: RE: clock_gettime function doesn't scale to real time.. and >changing CNTFRQ_EL0 doesn't make any change..(arm64) > > >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