[webkit-dev] Request for Position: Compute Pressure API
Olivier Yiptong
oyiptong at chromium.org
Thu May 6 10:55:29 PDT 2021
Hi, and thank you for your prompt response. Replies inline.
1. CPU utilization isn't something which can be easily computed or
> reasoned on asymmetric multi-core CPUs, not to mention the dynamic
> adjustment of CPU frequency further complicates the matter.
Are you alluding to CPU architectures like big.LITTLE? and of dynamic
clock frequencies?
This proposal takes this into account, here's how:
The utilization number returned aggregates how time was spent by the
active cores in various states since the last time a sample was taken.
i.e. for each active core, the time spent in idle/non-idle states are
compared and aggregated, to give an amount representative of the
overall system state.
This gives an idea of how system state changed over time, and takes
into account asymmetric multi-core CPU architectures.
As for dynamic clock frequencies, CPU speed also factors that, also
with data aggregated over all active cores.
As with utilization, each active core's clock frequency ranges and
state are noted, (i.e. minimum, base, maximum and current clock speed)
and aggregated.
This gives an overall idea of the system's clock speed, even if the
cores may have different clock speeds.
This is analogous to Apple's own CPU Power reporting API:
https://developer.apple.com/documentation/iokit/1557079-iopmcopycpupowerstatus?language=objc
Most particularly, the `cpu_speed_limit` concept, which returns a
number which represents where the clock speed lies within its
available range.
The goal of CPU Speed is to abstract away those details and provide
clock frequency data that is actionable and yet preserves user
privacy.
2. Whether the system itself is under a heavy CPU load or not should not
> have any bearing on how much CPU time a website is entitled to use because
> the background CPU utilization may spontaneously change, and the reason of
> a high or a low CPU utilization may depend on what the website is doing;
> e.g. a daemon which wakes up in a response to a network request or some
> file access.
On the web, people write one-size-fits-all applications. Those need to
run across devices of varying compute power capabilities.
For compute-intensive applications, this poses problems and leads to
bad UX in the absence of hints from the system.
The proposal does not enforce any additional usage of resources, but
instead allows apps to make informed decisions.
It is common for compute-intensive applications to self-throttle to
provide a good UX.
One example is gaming: reducing drawing distance, effects, texture
sizes or level of detail for geometries if it's affecting frame rate.
On the Nintendo Switch, game engines have the feature to reduce the
rendering resolution when framerate drops occur or are anticipated.
On the Nintendo Switch, the compute power capability depends on
whether the device is plugged in or in portable mode.
There might also be thermal factors.
For the Compute Pressure API, we've examined a few use-cases, and they
are detailed in the explainer.
This is similar to video conferencing needs, reducing the number of
simultaneous video feeds, or diminishing the processing of image
processing effects.
Indeed, the reason for the load might be intrinsic to the application,
or extrinsic, based on what's going on with the system.
This API, as proposed, provides system-level hints that help
applications make informed decisions to provide a good UX for users.
> 3. The proposal as it currently stands seems to allow a side channel
> communication between different top-level origins (i.e. bypasses storage
> partitioning). A possible attack may involve busy looping or doing some
> heavy computation in one origin and then observing that CPU utilization
> goes up in another. We've reported an attack of a similar nature in
> https://bugs.chromium.org/p/chromium/issues/detail?id=1126324.
Thanks for that insight. I'll look into it.
On Wed, May 5, 2021 at 1:27 PM Olivier Yiptong <oyiptong at chromium.org>
wrote:
> Yes, we've internally discussed how this can increase precision in
> fingerprinting.
>
> The result of these discussions resulted in mitigations that address this:
> https://github.com/oyiptong/compute-pressure#minimizing-information-exposure
>
> The main thrusts are as follows:
>
> - The UA can control how many bits of entropy by decided on how many
> thresholds are accepted from an observer request, effectively determining
> the number of "buckets" of information to expose
> - The values returned are "quantized" relative to the requested
> thresholds
> - The observer requests are rate-limited
> - The values returned are normalized within a known range
> - Per-core information is aggregated into a single value for both
> utilization and speed
>
> We are also applying some mitigations in our implementation, e.g. only
> allowing access to the API in visible pages, having a different update rate
> for visible tabs than for those that aren't visible, etc.
> We can also discuss implementation details if you're interested.
>
> On Wed, May 5, 2021 at 12:13 PM Alex Christensen <achristensen at apple.com>
> wrote:
>
>> Has anyone discussed how this can increase the precision of
>> fingerprinting? It seems to reveal more information or more precise
>> information about what else is going on on a user’s system.
>>
>> On May 5, 2021, at 11:37 AM, Olivier Yiptong via webkit-dev <
>> webkit-dev at lists.webkit.org> wrote:
>>
>> Hello WebKit devs,
>>
>> We'd like to get WebKit's position on the Compute Pressure API.
>>
>> Description:
>>
>> We propose a new API that conveys the utilization of CPU resources on the
>> user's device. This API targets applications that can trade off CPU
>> resources for an improved user experience. For example, many applications
>> can render video effects with varying degrees of sophistication. These
>> applications aim to provide the best user experience, while avoiding
>> driving the user's device in a high CPU utilization regime.
>>
>> High CPU utilization is undesirable because it strongly degrades the user
>> experience. Many smartphones, tablets and laptops become uncomfortably hot
>> to the touch. The fans in laptops and desktops become so loud that they
>> disrupt conversations or the users’ ability to focus. In many cases, a
>> device under high CPU utilization appears to be unresponsive, as the
>> operating system may fail to schedule the threads advancing the task that
>> the user is waiting for.
>>
>> Thanks!
>>
>>
>> - Specification Title: Compute Pressure API
>> - Specification URL: https://oyiptong.github.io/compute-pressure/
>> - Explainger:
>> https://github.com/oyiptong/compute-pressure/blob/main/README.md
>> - ChromeStatus.com entry:
>> https://chromestatus.com/features/5597608644968448
>> - TAG design review request:
>> https://github.com/w3ctag/design-reviews/issues/621
>> - Mozilla Request for Position:
>> https://github.com/mozilla/standards-positions/issues/521
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20210506/e738a814/attachment.htm>
More information about the webkit-dev
mailing list