Documentation/admin-guide/hw-vuln/core-scheduling.rst

Source file repositories/reference/linux-study-clean/Documentation/admin-guide/hw-vuln/core-scheduling.rst

File Facts

System
Linux kernel
Corpus path
Documentation/admin-guide/hw-vuln/core-scheduling.rst
Extension
.rst
Size
11380 bytes
Lines
227
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. SPDX-License-Identifier: GPL-2.0

===============
Core Scheduling
===============
Core scheduling support allows userspace to define groups of tasks that can
share a core. These groups can be specified either for security usecases (one
group of tasks don't trust another), or for performance usecases (some
workloads may benefit from running on the same core as they don't need the same
hardware resources of the shared core, or may prefer different cores if they
do share hardware resource needs). This document only describes the security
usecase.

Security usecase
----------------
A cross-HT attack involves the attacker and victim running on different Hyper
Threads of the same core. MDS and L1TF are examples of such attacks.  The only
full mitigation of cross-HT attacks is to disable Hyper Threading (HT). Core
scheduling is a scheduler feature that can mitigate some (not all) cross-HT
attacks. It allows HT to be turned on safely by ensuring that only tasks in a
user-designated trusted group can share a core. This increase in core sharing
can also improve performance, however it is not guaranteed that performance
will always improve, though that is seen to be the case with a number of real
world workloads. In theory, core scheduling aims to perform at least as good as
when Hyper Threading is disabled. In practice, this is mostly the case though
not always: as synchronizing scheduling decisions across 2 or more CPUs in a
core involves additional overhead - especially when the system is lightly
loaded. When ``total_threads <= N_CPUS/2``, the extra overhead may cause core
scheduling to perform more poorly compared to SMT-disabled, where N_CPUS is the
total number of CPUs. Please measure the performance of your workloads always.

Usage
-----
Core scheduling support is enabled via the ``CONFIG_SCHED_CORE`` config option.
Using this feature, userspace defines groups of tasks that can be co-scheduled
on the same core. The core scheduler uses this information to make sure that
tasks that are not in the same group never run simultaneously on a core, while
doing its best to satisfy the system's scheduling requirements.

Core scheduling can be enabled via the ``PR_SCHED_CORE`` prctl interface.
This interface provides support for the creation of core scheduling groups, as
well as admission and removal of tasks from created groups::

    #include <sys/prctl.h>

    int prctl(int option, unsigned long arg2, unsigned long arg3,
            unsigned long arg4, unsigned long arg5);

option:
    ``PR_SCHED_CORE``

arg2:
    Command for operation, must be one off:

    - ``PR_SCHED_CORE_GET`` -- get core_sched cookie of ``pid``.
    - ``PR_SCHED_CORE_CREATE`` -- create a new unique cookie for ``pid``.
    - ``PR_SCHED_CORE_SHARE_TO`` -- push core_sched cookie to ``pid``.
    - ``PR_SCHED_CORE_SHARE_FROM`` -- pull core_sched cookie from ``pid``.

arg3:
    ``pid`` of the task for which the operation applies.

arg4:
    ``pid_type`` for which the operation applies. It is one of
    ``PR_SCHED_CORE_SCOPE_``-prefixed macro constants.  For example, if arg4
    is ``PR_SCHED_CORE_SCOPE_THREAD_GROUP``, then the operation of this command
    will be performed for all tasks in the task group of ``pid``.

arg5:
    userspace pointer to an unsigned long long for storing the cookie returned

Annotation

Implementation Notes