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 146E6C433FE for ; Fri, 4 Nov 2022 12:05:00 +0000 (UTC) Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.96) (envelope-from ) id 1oqvRK-0004qB-3D; Fri, 04 Nov 2022 08:04:51 -0400 Received: from mail-ej1-x635.google.com ([2a00:1450:4864:20::635]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1oqvRJ-0004q3-0R for kernelnewbies@kernelnewbies.org; Fri, 04 Nov 2022 08:04:49 -0400 Received: by mail-ej1-x635.google.com with SMTP id k2so12737920ejr.2 for ; Fri, 04 Nov 2022 05:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=9kY/b3F7DVXOabYIM4u+k2/XoELMm4LTHJZBYdiiLfE=; b=MPLMMMfO4YxMFtlXjkUNg20NSZoaL68bM+K5fyVRXhorMKwoTRN1cbqNw0EqSzfpu9 Gfii5TdOCBImNVH6NUh723m0SRSB9vvwMMBe6hpYbEESkjJCYrwO5hXGKZ4MJWP8MPTv qcV6hZ9WhnnC8oGzJtdkgHWZn1cwM7Wzr30L0rzSDvEMEH1lj2W03y8S1UGX/lHdGTVm CXH5dYW1WSp86xD8gnPbfENZHX/ujrNHZHa1tGIBSRY0lp2ob9EVjGmrGl+/48Rwpu0G u+gSFjp3sdQTCyeaTxorN5w//yVCr32KzewHSOCmlYTUZjXxs9nkuh12Iq66pqUsQWWz 8H2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=9kY/b3F7DVXOabYIM4u+k2/XoELMm4LTHJZBYdiiLfE=; b=tl4NBebGVSCXFNMHmgjZl2EUokAbuhmmZEO4yY9GTD2LeE0aFt3okJIEYv2xLQVto7 M7OeHQYJVq0DoXCiGv6+1d0zXze/dNwIwHBPNaNDBCs9xEmCh0Okbf/uaWC5dpqj+8XV RBFd1Lg1G/kWEmuAtWWKRNKeq5Go+9PtoluFS/1hMRWLaZbWcrz57m0qTvpdDEJNjZL7 kvrStNGvI+/qRoQ7Z9W6jb9CRCWHr9NdF5OMC3w23wMoOyNHcAYJQd2brHh339VUZIYa QOnpMzSJ6dtzjDyNnyZtFkVdl2LkxvmBadh72TOEMWM7kozwWIvcUgLyOvwWJebBmQqT Nr+A== X-Gm-Message-State: ACrzQf3fxt4B72i+/MI1Kqbim2+gU2hU5dyMXIIXw2eSDwDCcPy/ctry bVD3mca3GqMRWIj9vh1KYRCg5yUcBhCQNbnm X-Google-Smtp-Source: AMsMyM5344wBagGIh1pnQEeNrRl7ltQ5GtkkY4E2nSFBoMomNxy1nrSmW7+QTlqawyoovQD9ax9egA== X-Received: by 2002:a17:907:6d9d:b0:7ad:f514:794e with SMTP id sb29-20020a1709076d9d00b007adf514794emr17392533ejc.602.1667563486155; Fri, 04 Nov 2022 05:04:46 -0700 (PDT) Received: from 5CG1448ZS9 (c188-150-77-196.bredband.tele2.se. [188.150.77.196]) by smtp.gmail.com with ESMTPSA id w12-20020a50fa8c000000b004585eba4baesm1822927edr.80.2022.11.04.05.04.45 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Nov 2022 05:04:45 -0700 (PDT) Date: Fri, 4 Nov 2022 13:04:43 +0100 From: Linus Probert To: kernelnewbies@kernelnewbies.org Subject: Re: clock_gettime function doesn't scale to real time.. and changing CNTFRQ_EL0 doesn't make any change..(arm64) Message-ID: References: <143801d8f02c$6a126f90$3e374eb0$@etri.re.kr> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <143801d8f02c$6a126f90$3e374eb0$@etri.re.kr> 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 On Fri, Nov 04, 2022 at 06:04:15PM +0900, 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. > Here is how I did it in the application. Hello, while I'm by no means an authority on kernel code and the board you are developing for I did spot some problems with your provided example code. > > 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); > } CLOCK_REALTIME is defined as "wall time" in `man clock_gettime` so it should not be impacted by the CPU frequency. > > 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); You are not converting seconds to milliseconds here but in the printf call below you are asuming it's the same time unit. > exec_time_nsec = (float)((double)(stop.tv_nsec - > start.tv_nsec)/(double)BILLION); 1 millisecond is 0.000001 nanoseconds. So you want MILLION here. Also, it's a lot of casting. > > printf("Execution time : %f sec\n", exec_time_sec + > exec_time_nsec); > > return 0; > } > > > 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! > I couldn't find how linux uses clock_gettime. > How can I solve this problem? > Any advice will be deeply appreciated. > > Thank you! > > Chan Kim > > > > I would suggest that you have a read through `man clock_gettime`. After fixing your code. In particular you might be interested in the actual CPU time clocks. That said. I'm not sure these are the system calls you should be looking at. Br, Linus Probert > _______________________________________________ > 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