Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lavd_lavd: initial support for AMP (asynmmetric multi-processor) architecture #452

Merged
merged 6 commits into from
Jul 27, 2024

Conversation

multics69
Copy link
Contributor

This is the initial support for AMP architecture, such as Intel Alder Lake (P/E). Initially, we tackle the problem from the core compaction point of view.

  • Now, the core compaction is AMP-aware, so the more performant core will be chosen first.
  • The time slice calculation is also AMP-aware, so the time slice on a CPU will be proportional to the CPU's capacity. Since a task on a more performant core will have a longer slice, but a task on a less performant core will get a shorter slice. This way, the performant core is more likely to be clock-boosted, and a task on a less performant core will have a higher chance of being scheduled on the more performant core.
  • Besides these two, there are some clean-ups and tuning related to the core compaction feature.

With these changes, the kernel compilation time (with default options) is reduced from 7:35 to 6:28 with "make -j3" on a 14-core (20-cpu) Raptor Lake processor.

Changwoo Min added 6 commits July 26, 2024 18:46
Remove unused constants and rename outdated constants to proper names
(LAVD_TC_* to LAVC_CC_* and LAVD_ELIGIBLE_DSQ to LAVD_GLOBAL_DSQ).

Signed-off-by: Changwoo Min <changwoo@igalia.com>
Signed-off-by: Changwoo Min <changwoo@igalia.com>
Signed-off-by: Changwoo Min <changwoo@igalia.com>
Previously, the core compaction assumed that each core's capacity was
the same. Now, we additionally consider each core's max clock frequency.
So, it always tries to use the higher-frequency cores first.

Signed-off-by: Changwoo Min <changwoo@igalia.com>
 With the --prefer-smt-core option is on, the core compaction prefers to
 utilizae hyper-twin first before utilizing the other physical CPUs. By
 default, the option is off.

Signed-off-by: Changwoo Min <changwoo@igalia.com>
When a task is running on more performant core, the scheduler will give
a longer time slice. On the other hand, on a less performant core, a
shorter time slice will be assigned. The longer time slice helps
boosting clock frequency on a performant core. Also, the shorter time
slice gives more chance the performant core being utilized.

Regarding the CPU capacity, we first check if kernel-provided capacitiy values
are trustworthy or not. If not (i.e., all the same values), we rely on
the user-provided value, based on each CPU's maximum clock frequency.

Signed-off-by: Changwoo Min <changwoo@igalia.com>
@multics69 multics69 requested a review from htejun July 26, 2024 14:45
@multics69 multics69 merged commit d4a5a62 into sched-ext:main Jul 27, 2024
1 check failed
@multics69 multics69 deleted the lavd-core-compaction-v2 branch July 27, 2024 07:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants