* cpufreq driver + wrong cpu time @ 2005-10-30 13:11 Alexander Shaposhnikov 2005-10-30 21:21 ` Eric Piel 0 siblings, 1 reply; 4+ messages in thread From: Alexander Shaposhnikov @ 2005-10-30 13:11 UTC (permalink / raw) To: linux-kernel Hello to everyone. I have written cpufreq_nForce4 kernel driver for cpufreq subsystem. It allows for CPU frequency changing by adjusting FSB speed, for nForce4 based motherboards. Works for single-cpu systems, as well as for SMP. The problem is, after changing CPU(s) speed on SMP systems, programs report wrong cpu time (wall time is OK). What would be the best way to fix this, and shouldn't this be done by the cpufreq subsystem, rather than by hardware driver? P.S Please include me in the CC explicitly! Best Regards, Alexander Shaposhnikov ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: cpufreq driver + wrong cpu time 2005-10-30 13:11 cpufreq driver + wrong cpu time Alexander Shaposhnikov @ 2005-10-30 21:21 ` Eric Piel 2005-10-31 5:44 ` Alexander Shaposhnikov 0 siblings, 1 reply; 4+ messages in thread From: Eric Piel @ 2005-10-30 21:21 UTC (permalink / raw) To: Alexander Shaposhnikov; +Cc: linux-kernel Alexander Shaposhnikov wrote: > Hello to everyone. > Hello Alexander, > I have written cpufreq_nForce4 kernel driver for cpufreq subsystem. > It allows for CPU frequency changing by adjusting FSB speed, for nForce4 > based motherboards. > Works for single-cpu systems, as well as for SMP. > The problem is, after changing CPU(s) speed on SMP systems, programs > report wrong cpu time (wall time is OK). What do you mean by CPU time? Do you mean the output of "time foo" ? How do you know the *right* CPU time? Could you provide some examples :-) Well, anyway, by _rough_ guess, if on UP it works and on SMP it doesn't, we could imagine that the difference comes from the fact the tick interrupt source is not the same on those systems. You could try to boot a UP kernel with local APIC (selectable in the .config) on the multi-processor computer to check. Then it might mean that after changing the FSB speed, the interrupt source has to be re-programmed... > What would be the best way to fix this, and shouldn't this be done by > the cpufreq subsystem, rather than by hardware driver? > Probably the best place to discuss about cpufreq is the dedicated mailing list : cpufreq@lists.linux.org.uk . If you don't mind, you could continue there. Also please, provide the sources of your driver to have a look :-) cu, Eric ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: cpufreq driver + wrong cpu time 2005-10-30 21:21 ` Eric Piel @ 2005-10-31 5:44 ` Alexander Shaposhnikov 0 siblings, 0 replies; 4+ messages in thread From: Alexander Shaposhnikov @ 2005-10-31 5:44 UTC (permalink / raw) To: Eric Piel; +Cc: cpufreq, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2053 bytes --] Hello Eric, Its my first foray into kernel driver programming, so please don't be too hard on me:) The total elapsed time (by "time foo") is OK. The problem is, cputime reported by, for example, "top" utility, is wrong. The same problem with fortran intrinsic routine "ETIME", so quantum chemistry codes i use (all written in fortran) reports wrong cputime, but correct "wall(elapsed) time". I've attached the code. I was able to test it only on my own dual Opteron system, so have no idea about other MB. P.S. Please include me in CC explicitly! Best Regards, Alexander Shaposhnikov On Mon, 2005-10-31 at 06:21 +0900, Eric Piel wrote: > Alexander Shaposhnikov wrote: > > Hello to everyone. > > > Hello Alexander, > > > I have written cpufreq_nForce4 kernel driver for cpufreq subsystem. > > It allows for CPU frequency changing by adjusting FSB speed, for nForce4 > > based motherboards. > > Works for single-cpu systems, as well as for SMP. > > The problem is, after changing CPU(s) speed on SMP systems, programs > > report wrong cpu time (wall time is OK). > What do you mean by CPU time? Do you mean the output of "time foo" ? How > do you know the *right* CPU time? Could you provide some examples :-) > > Well, anyway, by _rough_ guess, if on UP it works and on SMP it doesn't, > we could imagine that the difference comes from the fact the tick > interrupt source is not the same on those systems. You could try to boot > a UP kernel with local APIC (selectable in the .config) on the > multi-processor computer to check. Then it might mean that after > changing the FSB speed, the interrupt source has to be re-programmed... > > > What would be the best way to fix this, and shouldn't this be done by > > the cpufreq subsystem, rather than by hardware driver? > > > Probably the best place to discuss about cpufreq is the dedicated > mailing list : cpufreq@lists.linux.org.uk . If you don't mind, you could > continue there. > > Also please, provide the sources of your driver to have a look :-) > > cu, > Eric [-- Attachment #2: cpufreq_nForce4.tar.bz2 --] [-- Type: application/x-bzip-compressed-tar, Size: 6946 bytes --] [-- Attachment #3: Type: text/plain, Size: 147 bytes --] _______________________________________________ Cpufreq mailing list Cpufreq@lists.linux.org.uk http://lists.linux.org.uk/mailman/listinfo/cpufreq ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: cpufreq driver + wrong cpu time @ 2005-10-31 5:44 ` Alexander Shaposhnikov 0 siblings, 0 replies; 4+ messages in thread From: Alexander Shaposhnikov @ 2005-10-31 5:44 UTC (permalink / raw) To: Eric Piel; +Cc: linux-kernel, cpufreq [-- Attachment #1: Type: text/plain, Size: 2053 bytes --] Hello Eric, Its my first foray into kernel driver programming, so please don't be too hard on me:) The total elapsed time (by "time foo") is OK. The problem is, cputime reported by, for example, "top" utility, is wrong. The same problem with fortran intrinsic routine "ETIME", so quantum chemistry codes i use (all written in fortran) reports wrong cputime, but correct "wall(elapsed) time". I've attached the code. I was able to test it only on my own dual Opteron system, so have no idea about other MB. P.S. Please include me in CC explicitly! Best Regards, Alexander Shaposhnikov On Mon, 2005-10-31 at 06:21 +0900, Eric Piel wrote: > Alexander Shaposhnikov wrote: > > Hello to everyone. > > > Hello Alexander, > > > I have written cpufreq_nForce4 kernel driver for cpufreq subsystem. > > It allows for CPU frequency changing by adjusting FSB speed, for nForce4 > > based motherboards. > > Works for single-cpu systems, as well as for SMP. > > The problem is, after changing CPU(s) speed on SMP systems, programs > > report wrong cpu time (wall time is OK). > What do you mean by CPU time? Do you mean the output of "time foo" ? How > do you know the *right* CPU time? Could you provide some examples :-) > > Well, anyway, by _rough_ guess, if on UP it works and on SMP it doesn't, > we could imagine that the difference comes from the fact the tick > interrupt source is not the same on those systems. You could try to boot > a UP kernel with local APIC (selectable in the .config) on the > multi-processor computer to check. Then it might mean that after > changing the FSB speed, the interrupt source has to be re-programmed... > > > What would be the best way to fix this, and shouldn't this be done by > > the cpufreq subsystem, rather than by hardware driver? > > > Probably the best place to discuss about cpufreq is the dedicated > mailing list : cpufreq@lists.linux.org.uk . If you don't mind, you could > continue there. > > Also please, provide the sources of your driver to have a look :-) > > cu, > Eric [-- Attachment #2: cpufreq_nForce4.tar.bz2 --] [-- Type: application/x-bzip-compressed-tar, Size: 6946 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-10-31 5:44 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-10-30 13:11 cpufreq driver + wrong cpu time Alexander Shaposhnikov 2005-10-30 21:21 ` Eric Piel 2005-10-31 5:44 ` Alexander Shaposhnikov 2005-10-31 5:44 ` Alexander Shaposhnikov
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.