On Wed, May 18, 2016 at 2:38 PM, Prarit Bhargava <[email protected]> wrote: > > > On 05/17/2016 08:50 PM, Rafael J. Wysocki wrote: >> On Tue, May 17, 2016 at 1:34 PM, Prarit Bhargava <[email protected]> wrote: >>> intel_rapl is currently not supported in virtualized environments. When >>> booting the warning message >>> >>> intel_rapl: no valid rapl domains found in package 0 >> >> You seem to be saying that this message is problematic for some >> reason, so why is it? >> > > I thought about my previous answer and after thinking about it realized I > didn't > give you enough background Rafael. Virtual environments won't use this > feature > as this is meant for restricting power consumption at the HW level. > > So ... here's the situation. Most CPU features from Intel have a CPU feature > bit (also known in some circles as cpuflags) set for them. For example MCE > has > an mce bit that is exposed in /proc/cpuinfo. Unfortunately, for Intel RAPL > there is no bit (I don't know if someone dropped the ball or if Intel > intentionally left this feature off ... I've heard both explanations :)). > > In any case the Intel RAPL driver is one of the few cpu based drivers in the > kernel that still does a x86_match_cpu() against supported CPUs. This means > for > virtual cpus which export the host cpu's cpu model number, the intel_rapl > driver > will attempt to load for each cpu. > > As a result the message > > intel_rapl: no valid rapl domains found in package 0 > > is output as a *visible* error to the user for each virtual core. > > The error is valid for native cpus (although over 100s of systems I can say > I've > never seen the warning output on a native cpu) but it is clearly not valid for > virtual cpus *because virtualized systems don't use this feature*. > > The driver shouldn't load on virt systems. That's the bottom line here, and > the > patch prevents that from happening. Would I prefer that there were some other > mechanism to detect RAPL? Yep. I really really would. But beyond mucking > with > MSRs (which is definitely more complicated and awful than this simple check) I > don't see any easier method than the one I've proposed. > > I really don't want to be the one who sets the precedent of abusing x86_hyper > in > this way. I know it isn't the "right" thing to do -- but I honestly do not > see > a better or cleaner way out of this.
One quite obvious alternative might be to reduce the log level of the message in question, say to pr_debug.
