Arjan, Thanks for the explanation. I understand that hardcoding loops_per_jiffiy is a really really bad idea, and i have no intensions to hardcode it. I was just trying to find out reason for high CPU usage of the driver. As you said that loops_per_jiffy is used for udelay / mdelay, and and changing loops_per_jiffy is causing difference in performance, so can we conclude from this behaviour that either ethernet/wireless driver is using mdelay/udelay (directly or in some indirect way) in data path, and when i change loops_per_jiffy then they are simply waiting less when they calls mdelay / udelay which results in some increase in throughput? (Please note that these driver are not part of 2.6.11 kernel release, they are in devlopment stage currently) One more thing i wanted to know, On my Xscale platform kernel reports it to be 399.6 BogoMips and kernel running on my ARM11 platform reports 266.8 BogoMips (here i have not touched loops_per_jiffy :)). Since both processors are running at 400MHz, so can you please explain what may be possible reasons for the difference difference in BogoMips values? I am trying to debug why same drivers are giving different CPU usage on ARM11 and Xscale, both processors are of almost same capability, on Xscale i am getting very good performance with these drivers and on ARM11 i am getting really bad performnace. Thanks, pankaj ----- Original Message ---- From: Arjan van de Ven <arjan@xxxxxxxxxxxxx> To: pankaj chauhan <chauhan_ait@xxxxxxxxxxx> Cc: kernelnewbies@xxxxxxxxxxxx Sent: Thursday, 21 December, 2006 2:44:21 PM Subject: Re: loops_per_jiffy: query > I tried to tweek the value of loops_per_jiffy manually (just for testing, i have no intensions of replacing calibration function :)) on my ARM11. For example setting loops_per_jiffiy value such tthat i get 140 BogoMips, the throughput incereased considerably to 66Mbps, but CPU usage remained around 85%. And using diffrent hard coded values of loops_per_jiffy i got diffrenent Throughput values and CPU usages. loops_per_jiffy is used in udelay() and mdelay() functions, which are delay loops for a certain amount of micro/miliseconds. What you did is artificially override drivers that wanted to delay a certain time to delay shorter. This is usually a very bad idea; those delay loops are there for a reason (although some device drivers are just plain stupid and abuse them a lot... which network driver did you use?) -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/ Send free SMS to your Friends on Mobile from your Yahoo! Messenger. Download Now! http://messenger.yahoo.com/download.php -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
