Are there any methods (linux kernel options, sysctl settings or configurable scheduler modules) that can cause a high priority process/thread to run on a physical processor core with the second (hyper threading) virtual core unscheduled in order to maximize single thread performance (by preventing from competitive situations, not sharing the L1 cache and the possible use of maximum cpu clock - Turbo Boost), while at the same time running lower priority processes/threads on both virtual cores of other physical cores with lower cpu clock to maximize total system throughput ?

In other words: Is it possible to disable hyper threading dynamically based on priority ?

In case there are any CPUs using the process/thread priority to decide which of the two threads on a hyper threading core is allowed to make progress first in a competitive situation, is the linux kernel able to schedule high priority processes/threads such that they share the physical core only with very low priority processes/threads in order to minimize their effect on the other thread ?

While the high priority process is sleeping, both virtual cores of its former physical core should again become available for lower priority processes, which makes it inappropriate to use taskset to exclude one physical core from the CPU affinity mask of all other processes.

Edit: With the advent of the Alder Lake processor with its hybrid architecture of performance and efficient cores, this question extends to:

How to force low-priority processes to the efficient cores and keep the performance cores either idle (to save power) or reserved for high-priority processes (to reserve thermal budget in order to maximize Turbo Boost) ?

  • "while at the same time running…" What do you precisely mean ? v.g in particular : If the process getting the high priority (and therfore having hyper threading disabled) blocks waiting for whatever event and being for that matter scheduled out to the benefits of a lesser priority process being scheduled in, would you want that, for the time that lesser priority process runs, hyper hreading to be reactivated and then automagically re-deactivated when the higher priority process gets re-scheduled in ?
    – MC68020
    Commented Jan 26, 2023 at 21:30
  • In addition, if that high priority process gets (upon user request) at run time its priority restored to a default priority, should hyperthreading be automagically reenabled ?
    – MC68020
    Commented Jan 26, 2023 at 21:36
  • @MC68020, yes to both questions: That's what I would want :-) Or to say it in other words: Every time the scheduler runs, the decisions should be made like the question suggests.
    – Juergen
    Commented Jan 26, 2023 at 23:17

1 Answer 1

  • What you precisely want (in particular what being discussed in OP's comments) would need to on/off-line some core right in sync with task switching => Only the scheduler could do that.
  • The set of cores made available for the purpose of running tasks scheduled by the scheduler is a constraint made to the scheduler. (i.e. not something the scheduler can control AFAIK regarding CFS, BFS and ULE)

There is consequently just no way to achieve exactly what you want.

There are nevertheless some possibilities to have that happen thanks to some independent kernel facilities but, there is no free lunch, with varying costs depending on the application running with high priority.

One idea would be to write a dedicated script for launching those applications, special script that would :

1/ Offline the undesirable sibling

Ok, this assumes you know the physical core that will run the task, let's say cpu2. But you necessarily know which one it is. Read §2.

This being achievable by writing 0 to /sys/devices/system/cpu/cpu3/online

2/ Set the process' CPU affinity

As you write it, your first goal is to preserve the L1 cache as much as possible. If you care that much of the L1 cache you consequently do not want the task to be migrated to another core at any time upon scheduler's decision based on fair sharing.
This can be achieved via several ways, for a reason you'll discover in §3, I'd prefer resorting to schedtool and its -a option, admitting cpu2 desired :

schedtool -a 0x4 -e yourapp_name yourapp_parms

3/ Set process' scheduling policy and priority

Scheduling the task SCHED_FIFO will greatly help since there is no time slice and the task will only be scheduled out if a task of a higher priority is to be run or if it blocks.
There are several ways to achieve this, with schedtool using the -F and - p options :

schedtool -F -p 5 -e yourapp_name yourapp_parms

I prefer schedtool because you can just merge the affinity setting and the scheduling policy setting into a single command :

schedtool -a 0x04 -F -p 5 -e yourapp_name yourapp_parms

HANDLE WITH CARE : You enter the world of real-time tasks… so… you know what you are doing. In particular… if your tasks are CPU-bound, you know you have to care with relative priority of other tasks running SCHED_FIFO on your system and of course realize the extreme absurdity of having at some time the other cores running other SCHED_FIFO CPU-Bound tasks…

4/ Replug the initially offlined sibling when the task finishes

This being achievable by writing 1 to /sys/devices/system/cpu/cpu3/online


Following this method, you understand that the sibling will be made available for the scheduler only when your privileged task terminates.
While this is not problematic if running a CPU-Bound task SCHED_FIFO (since it would never or pretty rarely be scheduled out, it might well appear harmful (from an overall performance standpoint) if the privileged task is in fact IO-bound. In other words spends a significant amount of clock-time blocked waiting for external events.
Because in this case, the privileged task will (rightly) be scheduled out and another task will take the CPU (possibly wiping your dear L1 cache) and the sibling remain offlined during all the time of the wait.

Therefore, as usual, only benchmarking your system under its typical workload can tell if this method indeed carries any significant benefit.

  • Thanks for that comprehensive answer. It seems the same reasoning applies to the second part of my question (how to force low-priority processes to the Alder Lake efficient cores): The scheduler cannot infer CPU affinity from process priority, so I need to taskset or schedtool the efficient cores to low priority processes explicitly. Is that true ?
    – Juergen
    Commented Feb 2, 2023 at 12:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .