Many Power Management Updates For The Linux 4.10 Kernel

[gilboa]

Ok in fact in the hypothesis C1E is enabled in a system where the CPU provides constant TSC, probably some problems happen and HPET should intervene based on what I've red in some web page, otherwise the system should hangs itself. However I hope to have understand wrong.

I'm not sure I understand.
HPET and (C)TSC are two different things.

Plus, AFAIK at least in Linux TSC is used instead of HPET as clock source.

- Gilboa

[Azrael5]

Hi,

Our software is installed on both mid to high-end servers (1/2/4S and above) and high-end demo laptops (running Fedora, that are shipped to our sales people).
While we tested TSC heavily on servers, we usually only verify that the software more-or-less works on laptops.

That said, we rely heavily on TSC for timing calculation and throws a big-fat warning if it encounters any type of major (more than a couple 100ns) TSC clock drifts.
As far as I remember I've yet to see any clock drifts on skylake laptops w/ all the power management options enabled (I would imagine that both C1E and EIST are enabled by default).

- Gilboa

Ok in fact in the hypothesis C1E is enabled in a system where the CPU provides constant TSC, probably some problems happen and HPET should intervene based on what I've red in some web page, otherwise the system should hangs itself. However I hope to have understand wrong.

[gilboa]

ok anyway have you examined on how constant OR invariant TSC affect CPU states on EIST or C1E!?


«The Linux kernel uses different time sources. The most interesting are the HPET (High Precision Event Timer) and the TSC (Time Stamp Counter).
The TSC is the preferred clocksource between the two counters, as it is the fastest one, however it can only be used if it is stable. Currently there are 4 types of TSC present:

1. Constant. Constant TSC means that the TSC does not change with CPU frequency changes, however it does change on C state transitions.
2. Invariant. As described in the Intel manual: “The invariant TSC will run at a constant rate in all ACPI P-, C- and T-states”
3. Non-stop. The Non-stop TSC has the properties of both Constant and Invariant TSC.
4. None of the above. The TSC changes with the C, P and S state transitions».

Hi,

Our software is installed on both mid to high-end servers (1/2/4S and above) and high-end demo laptops (running Fedora, that are shipped to our sales people).
While we tested TSC heavily on servers, we usually only verify that the software more-or-less works on laptops.

That said, we rely heavily on TSC for timing calculation and throws a big-fat warning if it encounters any type of major (more than a couple 100ns) TSC clock drifts.
As far as I remember I've yet to see any clock drifts on skylake laptops w/ all the power management options enabled (I would imagine that both C1E and EIST are enabled by default).

- Gilboa

[Azrael5]

AFAIK, if constant TSC is supported by the CPU, C1E / EIST should not make a difference.
However, take what I say with a *large* grain of salt, as I didn't test it myself.

I'd write a small tester - comping rdtsc vs wall clock with EIST and w/o it. See if it makes a difference.

- Gilboa

ok anyway have you examined on how constant OR invariant TSC affect CPU states on EIST or C1E!?


«The Linux kernel uses different time sources. The most interesting are the HPET (High Precision Event Timer) and the TSC (Time Stamp Counter).
The TSC is the preferred clocksource between the two counters, as it is the fastest one, however it can only be used if it is stable. Currently there are 4 types of TSC present:

1. Constant. Constant TSC means that the TSC does not change with CPU frequency changes, however it does change on C state transitions.
2. Invariant. As described in the Intel manual: “The invariant TSC will run at a constant rate in all ACPI P-, C- and T-states”
3. Non-stop. The Non-stop TSC has the properties of both Constant and Invariant TSC.
4. None of the above. The TSC changes with the C, P and S state transitions».

[gilboa]

I ask to know if c1e and or EIST should be disabled in the BIOS when the CPU supports only CONSTANT TSC (constant= NOT INVARIANT). TSC si base on processor CLOCK so if TSC si CONSTANT how can it manage for C1E or EIST STATES!? THANKS.

AFAIK, if constant TSC is supported by the CPU, C1E / EIST should not make a difference.
However, take what I say with a *large* grain of salt, as I didn't test it myself.

I'd write a small tester - comping rdtsc vs wall clock with EIST and w/o it. See if it makes a difference.

- Gilboa

[Azrael5]

I'm not sure I understand your request: You want the kernel to enforce zero-PM on machines that doesn't support constant TSC?
Why? Kernel / user-land developers on such platforms should be aware of this limitation and use other clock sources instead of TSC...

- Gilboa

I ask to know if c1e and or EIST should be disabled in the BIOS when the CPU supports only CONSTANT TSC (constant= NOT INVARIANT). TSC si base on processor CLOCK so if TSC si CONSTANT how can it manage for C1E or EIST STATES!? THANKS.

[gilboa]

And in the case of C, I wouldn't expect compilers to have optimizations specific to a function like atomic_fetch_add.

In the end, someone wrote a bunch of asm OPs and shove'm in a place GCC optimizer cannot touch

- Gilboa

[indepe]

Doubt it.
ASM code usually stays untouched.

And in the case of C, I wouldn't expect compilers to have optimizations specific to a function like atomic_fetch_add.

[gilboa]

[/SIZE]

Also, as I just looked up, LOCK ADD may be a cycle faster than LOCK XADD, which std C probably uses, based on the API, unless the compiler optimizes that when the return value is not used.

Doubt it.
ASM code usually stays untouched.

- Gilboa

[indepe]

Back when I started working on it, it wasn't in std library.
Plus, I rather not be limited to modern compilers (I still support older GCC and MSVC).

Also, as I just looked up, LOCK ADD may be a cycle faster than LOCK XADD, which std C probably uses, based on the API, unless the compiler optimizes that when the return value is not used.