

It’s not that uncommon for games to stutter for 50 ms, e.g. when an async task on a worker thread takes too long and holds up the rest of the game, or when something needs loading. For a Unity-based game, garbage collection can block the main thread for that long if the developer wasn’t careful, too. It’s also only sampling every 10 ms rather than recording every power state change, so a game that takes less than 10 ms to actually do its processing has a decent chance of missing any sampling points for a while.
The exact quote from the mailing list is:
The 300 ms decay is sized so that a render thread which is only 50-80% busy from periodic vsync and GPU-fence waits holds the boost across its whole busy period at a couple of CPPC_REQ writes total, while an idle core sheds the boost well before it can matter. The energy exposure of a wide window is small because EPP only influences behavior in C0 and an idle core sits in CC6 regardless. If folks want me to make these tunable I am happy to expose them.









It’s not really the intended use case of Lua to be used in things that will be upgraded after they’re released. It’s meant for things that need to work exactly the same way in a decade as they do now, and that’s best served by sticking to a specific version and either only upgrading to bugfix releases, or sticking to one specific commit forever. Those use cases also are better served by sticking to old versions of any libraries they use that are written in Lua (otherwise they might be hit by regressions or turn out to have been reliant on old buggy behaviour that’s been fixed), so probably aren’t upgrading to newer versions. That’s why the article is making the point that it’s not worthwhile for the maintainers of those libraries to keep compatibility with old versions of Lua as the people still using old versions of Lua are probably going to be sticking to old versions of those libraries, too.