[Bug 60839] scaling_max_freq cannot be set to values larger than bios_limit

[bugzilla-daemon@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=60839

Lan Tianyu <tianyu.lan@intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |ASSIGNED

--- Comment #3 from Lan Tianyu <tianyu.lan@intel.com> ---
(In reply to Sven Köhler from comment #2)
> (In reply to Lan Tianyu from comment #1)
> > Hi:
> >      This sounds like a user space issue. Bios limit will rise after
> > plugging/unplugging AC and laptop-mode-tools also should update
> > scaling_max_freq. Cpufreq core schedules freq scope according user space
> > configuration. If user space tool doesn't extend the scope according bios
> > limit after plugging/unplugging AC, the scope will keep low cpufreq.
> 
> First of all, does the kernel provide any hook to run a script every time
> bios_limit changes or do you expect userspace to do polling?

When bios limit is changed, ACPI processor driver will send an ACPI event to
user space.

> 
> Second, you can't be serious that the sysfs interface should remain as
> inconsistent as it is now.

The scaling_max/min_freq shows current policy limit. Kernel side also will
change the limit besides user space configuration and so it's inconsistent with
the data set to the attribute.

> Clearly, the internal state of scaling_max_freq
> and bios_limit can be one, 

No, actually there are some other factors that may change policy limit(E,G,
processor throttling controlled by thermal core).

> where scaling_max_freq is larger than bios_limit.
> This is very clear since I observed that (unless userspace tries to change
> scaling_max_freq) the value of scaling_max_freq will increase as bios_limit
> increases. At time when bios_limit is low, userspace cannot even find out
> about the true state of scaling_max_freq (which is larger than bios_limit)
> as the value obtainable via sysfs is always clipped. Obviously, knowing that
> such a state exists, it is dubious why it can't be configured.
>

Kernel will store the userspace configuration but not show. I think we can
introduce some new attributs to show user space configurations if necessory.

> Thirdly, I'd really like know the rational behind the decision to that 
> a) userspace should never be able to observe, that scaling_max_freq is
> actually kernel internally larger than bios_limit

I think you said the user space configuration rather than current
policy(scaling_min/max_freq shows). The current policy should take the
bios_limit into account.

> b) userspace should never be able to set scaling_max_freq to a value larger
> than bios_limit

Actually, you can set the value larger than bios_limit and it will works when
bios_limit raises.

> 
> IMHO, both (a) and (b) are wrong, in the sense that there is no good reason
> in favour of (a) and (b) and many reasons against (a) and (b). A very strong
> reason against (a) is the very simple fact that userspace cannot tell
> whether the current maximum CPU frequency is limited by the BIOS or the
> value of scaling_max_freq.

Actually, the cpu freq may be limited by other factors besides bios limit. So
new attributes may be helpful to identify whether kernel side has changed the
cpufreq scope.

-- 
You are receiving this mail because:
You are the assignee for the bug.