https://bugzilla.kernel.org/show_bug.cgi?id=60839 Lan Tianyu <tianyu.lan@xxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |ASSIGNED --- Comment #3 from Lan Tianyu <tianyu.lan@xxxxxxxxx> --- (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.-- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
