could blas-atlas disable cpu frequency throttling before it compiles and then restore it to whatever it was? (this would also save a lot of bug reports when blas complains about inconsistencies.) Reproducible: Always
(In reply to comment #0) > could blas-atlas disable cpu frequency throttling before it compiles and then > restore it to whatever it was? (this would also save a lot of bug reports when > blas complains about inconsistencies.) > > Reproducible: Always > We have implemented a HUGE warning: ewarn "Please make sure to disable CPU throttling completely" ewarn "during the compile of blas-atlas. Otherwise, all atlas" ewarn "generated timings will be completely random and the" ewarn "performance of the resulting libraries will be degraded" ewarn "considerably." It is up to the user, if he will disable CPU throttling etc. Ebuilds should not change kernel parameters, because it's dangerous and for a lot of other reasons.
I know. I have seen the warning. It is why I am telling you this. why not: "if cpufreq-set is installed, for all CPUs, save throttling state cpufreq-set to performance mode install blas-atlas restore throttling state else install blas-atlas provide the huge ewarn description, perhaps with a note that says "if you want it to happen automatically, install cpufreq-info." fi blas-atlas revises often (thanks guys). it is a pain to have to do this by hand every week or so---and most users have to do it by hand now: first scan if blas-atlas is in the world updates; if so, then disable throttling; then install; then recall state. it was just a suggestion...
As you insist, I will assign the bug to ther proper team which will make any decision. But I still don't find it a good idea, for many reasons including: 1) It's not good to change kernel parameters in high-end production servers, specifically when you do it from inside an ebuild, In a world update, a sysadmin just wants(expects) to update packages and not to change the "system's behaviour" 2) You created the above algorithm, but it's not so simple to implement it. 3) Does it worth?
hi panagiotis---I don't insist, I just suggest. Let me respond, though. Your first point is correct, but then blas-atlas should really refuse to build when cpu throttling is on. the blas-atlas build will be crap, and it would be better if it never happened. moreover, it may even abort due to inconsistency during the build. the warning message is really insufficient. [I admit to just letting it run incorrectly. when I need to use it, I rebuild.] On your other two points, you know more than I. however, naively, I would have thought that this should not be too difficult. cpufreq-info has a lot of nice switches to tell you what it is currently running at. cpufreq-set makes it straightforward to run, too. /iaw
Hi Ivo, Thanks much for the suggestion. I've thought about this myself in the past, but I am not sure if it is possible to reliably do this on all machines/motherboards without writing a whole lot of infrastructure code. I personally don't use CPU throttling at all so I'd had to investigate this in more detail. Also, there is probably no good way to bring the machine back into its previous state should the build fail for some reason which is unpleasant. However, if you have any good suggestions on how to do this please let me know. I'll investigate some more to see if we can find a solution that works for most people. I a sense, atlas is somewhat special since it requires the user to (sort of) know what she/he is doing. E.g. even with CPU throttling turned off, a CPU intensive task running during the emerge of atlas may screw up the timings. You could always mask the ~ARCH branch of atlas if you don't want to be bothered by it. Best, Markus
Here is my suggestion. First, if cpufreq-info is installed, run $cpufreq-info -p 1650000 2475000 ondemand if the governor (third token) is not "performance", print a warning and do not compile. Second, split up the install and the compile. so, blas-atlas-compile is installed, and it initiates the compile of blas-atlas at a later time (when the user has unthrottled). {PS: vanilla-sources uses a similar scheme: install, but do not compile.} actually, it is the blas-atlas compile that should execute the check above and abort or continue; the download can proceed in any case. these are just suggestions, which I hope would be easy to do, and make it better. feel free to ignore. thanks for having put in all the work. regards, /iaw
Maybe it would make more sense to try and detect CPU throttling and exit with error if it's found. Add an "ignorethrottle" USE flag to bypass the detection.
(In reply to comment #7) > Maybe it would make more sense to try and detect CPU throttling and exit with > error if it's found. Add an "ignorethrottle" USE flag to bypass the detection. > Is there some way to do such a test early, to avoid this scenario: emerge -auDv world Compile for 10min; 5 hours to go Go to bed ten minutes later atlas crash Wake up, still need 4 hours 50 min of compiling :-) /Jakob
This is included in the sci-libs/atlas ebuild in bicatali overlay.
Fixed in sci-libs/atlas in sci overlay.
