Kernel 5.9 RC (Release Candidate) series

[Doug S]

Kernel 5.9-rc1 is available from kernel.org, and the Ubuntu Mainline PPA.

I have been running very close to 5.9-rc1 all day.

We have a running thread during each mainline kernel release cycle.

Previous cycle threads: 5.8, 5.7, 5.6, 5.5, 5.4, 5.3, 5.2, 5.1, 5.0, 4.20, 4.19 ?, 4.18, 4.17, 4.16, 4.15, 4.14.

I can only comment on the stuff I work with and know about: The intel_pstate driver is introducing "passive mode with HWP enabled". This changes the default behavior of the grub command line option "intel_pstate=passive", as that used to imply to disable HWP. Now it doesn't. So if you want to run passive without HWP, you have to specify both.

Also, they are starting to tighten MSR (Machine Specific Register) access. So you need to specify that now also, or change it afterwards.

So, an example grub command line option:

GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 consoleblank=450 intel_pstate=passive intel_pstate=no_hwp msr.allow_writes=on cpuidle_sysfs_switch cpuidle.governor=teo"

Actually, I think the idle governor switch enable isn't needed anymore. I'll check and edit this later (test in progress at the moment).

After boot MSR write access control is via "/sys/module/msr/parameters/allow_writes", [on/off/default].

EDIT: Ya, the idle governor switch enable command line thing isn't needed anymore and since 5.8-rc1:

b52e93e4e86c cpuidle: Make cpuidle governor switchable to be the default behaviour
$ git tag --contains b52e93e4e86c
v5.8
v5.8-rc1
v5.8-rc2
v5.8-rc3
v5.8-rc4
v5.8-rc5
v5.8-rc6
v5.8-rc7
v5.9-rc1

[corradoventu]

canidate or candidate?

[zika]

canidate or candidate?

What is the meaning of word: canidate? I can not find it, eve though I've tried hard. To see where is possible missunderstanding...

[dino99]

Simply pointing to the missing 'd' wile typing , aka typo

[Doug S]

canidate or candidate?

Yes, typo. It should be candidate. I can not figure out how to edit the title.

[sudodus]

Yes, typo. It should be candidate. I can not figure out how to edit the title.

Edit post #1, select 'Advanced', and there is a box, where you can edit the title.

By the way, is there something in particular, that you think is good or bad with this new kernel?

[Doug S]

Edit post #1, select 'Advanced', and there is a box, where you can edit the title.

Oh, thanks. Yes, I forgot to go to "advanced".

By the way, is there something in particular, that you think is good or bad with this new kernel?

Oh Boy, I don't know how much to get into it. I have been having a spat with Intel (at least the members of the linux power management group) for many months now. HWP (HardWare Pstate) control does not work properly and can result in overruns for busy periodic workflows. For the new "passive mode with HWP enabled", pretty much all of my tests, so far, suggest that it uses more power, sometimes a lot more, when compared to passive with HWP disabled or the acpi-cpufreq driver with the same governor. I could go on and on. There are a great many e-mails on the linux-pm list about it. This is one reference from a couple of days ago. To be fair, we should let this play out before venting too much.

An obvious question is why don't I just use the acpi-cpufreq driver and move on? Because the "tools/power/x86/intel_pstate_tracer/intel_pstate_tracer.py" is a very good system debugging tool (I wrote most of it) and I would like to be able to use it.

Beyond the intel_pstate driver and idle stuff, I don't really follow other kernel changes.

[sudodus]

Thanks Doug S

[kevdog]

What does HWP actually target? Why would I want to make these changes or stay with the defaults? I understand your workaround which is pretty straightforward but just an in general question of why I should care.

[Doug S]

What does HWP actually target?

Within the intel_pstate CPU frequency scaling driver, and for new enough processors (>= 6th gen (A.K.A Skylake)), HWP (HardWare Pstate) control offloads the actual work into the processor itself.

Why would I want to make these changes or stay with the defaults?

For some time now, the intel_pstate driver has had a mode called "passive", a.k.a. intel_cpufreq, basically implementing similar functionality and governors as the acpi-cpufreq CPU frequency scaling driver, without the limitations of just a few frequencies. Until this kernel 5.9-rc1, setting intel_pstate=passive on the command line also implied HWP, if the processor had it, would be disabled. Now it doesn't. My OP comments were an attempt to make users aware of this change.

Now, until a few months ago, I never owned an Intel processor with HWP (I had a i7-2600k on my test server). I was rather surprised to discover that it doesn't actually work properly. It seems to get confused with periodic workflow, thinking the system is idle and fully spinning down. Rather than idle exit latencys on the order of 10's of microseconds, they become 10's of milliseconds (when one includes full frequency spin up time), causing overruns in the workflow. This is a timing window type event and rather low probability, Anyway, for me that is why I run always with intel_pstate=passive. The new passive with HWP is relatively untested, and users might be surprised to find they are running it instead of the "passive" they are used to.

I understand your workaround which is pretty straightforward but just an in general question of why I should care.

In reality, I think most people either run the defaults, which would be intel_pstate active mode with HWP if they have it or no HWP if they don't, or intel_pstate=disable, which would then be acpi_cpufreq. I think most, including Intel, don't care.

In terms of the road map for the kernel, a lot of effort is being put into the schedutil frequency scaling governor and it will be the preferred governor in the future. Some of this stuff is a stepping stone in that direction.