Hi all:
The core frequency is subjected to the process variation in semiconductors.
Not all cores are able to reach the maximum frequency respecting the
infrastructure limits. Consequently, AMD has redefined the concept of
maximum frequency of a part. This means that a fraction of cores can reach
maximum frequency. To find the best process scheduling policy for a given
scenario, OS needs to know the core ordering informed by the platform through
highest performance capability register of the CPPC interface.
Earlier implementations of amd-pstate preferred core only support a static
core ranking and targeted performance. Now it has the ability to dynamically
change the preferred core based on the workload and platform conditions and
accounting for thermals and aging.
Amd-pstate driver utilizes the functions and data structures provided by
the ITMT architecture to enable the scheduler to favor scheduling on cores
which can be get a higher frequency with lower voltage.
We call it amd-pstate preferred core.
Here sched_set_itmt_core_prio() is called to set priorities and
sched_set_itmt_support() is called to enable ITMT feature.
Amd-pstate driver uses the highest performance value to indicate
the priority of CPU. The higher value has a higher priority.
Amd-pstate driver will provide an initial core ordering at boot time.
It relies on the CPPC interface to communicate the core ranking to the
operating system and scheduler to make sure that OS is choosing the cores
with highest performance firstly for scheduling the process. When amd-pstate
driver receives a message with the highest performance change, it will
update the core ranking.
Changes form V6->V7:
- x86:
- - Modify kconfig about X86_AMD_PSTATE.
- cpufreq: amd-pstate:
- - modify incorrect comments about scheduler_work().
- - convert highest_perf data type.
- - modify preferred core init when cpu init and online.
- acpi: cppc:
- - modify link of CPPC highest performance.
- cpufreq:
- - modify link of CPPC highest performance changed.
Changes form V5->V6:
- cpufreq: amd-pstate:
- - modify the wrong tag order.
- - modify warning about hw_prefcore sysfs attribute.
- - delete duplicate comments.
- - modify the variable name cppc_highest_perf to prefcore_ranking.
- - modify judgment conditions for setting highest_perf.
- - modify sysfs attribute for CPPC highest perf to pr_debug message.
- Documentation: amd-pstate:
- - modify warning: title underline too short.
Changes form V4->V5:
- cpufreq: amd-pstate:
- - modify sysfs attribute for CPPC highest perf.
- - modify warning about comments
- - rebase linux-next
- cpufreq:
- - Moidfy warning about function declarations.
- Documentation: amd-pstate:
- - align with ``amd-pstat``
Changes form V3->V4:
- Documentation: amd-pstate:
- - Modify inappropriate descriptions.
Changes form V2->V3:
- x86:
- - Modify kconfig and description.
- cpufreq: amd-pstate:
- - Add Co-developed-by tag in commit message.
- cpufreq:
- - Modify commit message.
- Documentation: amd-pstate:
- - Modify inappropriate descriptions.
Changes form V1->V2:
- acpi: cppc:
- - Add reference link.
- cpufreq:
- - Moidfy link error.
- cpufreq: amd-pstate:
- - Init the priorities of all online CPUs
- - Use a single variable to represent the status of preferred core.
- Documentation:
- - Default enabled preferred core.
- Documentation: amd-pstate:
- - Modify inappropriate descriptions.
- - Default enabled preferred core.
- - Use a single variable to represent the status of preferred core.
Meng Li (7):
x86: Drop CPU_SUP_INTEL from SCHED_MC_PRIO for the expansion.
acpi: cppc: Add get the highest performance cppc control
cpufreq: amd-pstate: Enable amd-pstate preferred core supporting.
cpufreq: Add a notification message that the highest perf has changed
cpufreq: amd-pstate: Update amd-pstate preferred core ranking
dynamically
Documentation: amd-pstate: introduce amd-pstate preferred core
Documentation: introduce amd-pstate preferrd core mode kernel command
line options
.../admin-guide/kernel-parameters.txt | 5 +
Documentation/admin-guide/pm/amd-pstate.rst | 58 +++++-
arch/x86/Kconfig | 5 +-
drivers/acpi/cppc_acpi.c | 13 ++
drivers/acpi/processor_driver.c | 6 +
drivers/cpufreq/amd-pstate.c | 197 ++++++++++++++++--
drivers/cpufreq/cpufreq.c | 13 ++
include/acpi/cppc_acpi.h | 5 +
include/linux/amd-pstate.h | 6 +
include/linux/cpufreq.h | 5 +
10 files changed, 291 insertions(+), 22 deletions(-)
--
2.34.1
This series includes few assorted fixes for KVM RISC-V ONE_REG interface
and KVM_GET_REG_LIST API.
These patches can also be found in riscv_kvm_onereg_fixes_v2 branch at:
https://github.com/avpatel/linux.git
Changes since v1:
- Addressed Drew's comments in PATCH4
Anup Patel (4):
RISC-V: KVM: Fix KVM_GET_REG_LIST API for ISA_EXT registers
RISC-V: KVM: Fix riscv_vcpu_get_isa_ext_single() for missing
extensions
KVM: riscv: selftests: Fix ISA_EXT register handling in get-reg-list
KVM: riscv: selftests: Selectively filter-out AIA registers
arch/riscv/kvm/vcpu_onereg.c | 7 ++-
.../selftests/kvm/riscv/get-reg-list.c | 58 ++++++++++++++-----
2 files changed, 47 insertions(+), 18 deletions(-)
--
2.34.1
This series includes few assorted fixes for KVM RISC-V ONE_REG interface
and KVM_GET_REG_LIST API.
These patches can also be found in riscv_kvm_onereg_fixes_v1 branch at:
https://github.com/avpatel/linux.git
Anup Patel (4):
RISC-V: KVM: Fix KVM_GET_REG_LIST API for ISA_EXT registers
RISC-V: KVM: Fix riscv_vcpu_get_isa_ext_single() for missing
extensions
KVM: riscv: selftests: Fix ISA_EXT register handling in get-reg-list
KVM: riscv: selftests: Selectively filter-out AIA registers
arch/riscv/kvm/vcpu_onereg.c | 7 ++-
.../selftests/kvm/riscv/get-reg-list.c | 58 ++++++++++++++-----
2 files changed, 47 insertions(+), 18 deletions(-)
--
2.34.1
Hi Jens,
Can you consider taking this through the block tree?
These patches make some changes to the kunit tests previously added for
iov_iter testing, in particular adding testing of UBUF/IOVEC iterators and
some benchmarking:
(1) Clean up a couple of checkpatch style complaints.
(2) Consolidate some repeated bits of code into helper functions and use
the same struct to represent straight offset/address ranges and
partial page lists.
(3) Add a function to set up a userspace VM, attach the VM to the kunit
testing thread, create an anonymous file, stuff some pages into the
file and map the file into the VM to act as a buffer that can be used
with UBUF/IOVEC iterators.
I map an anonymous file with pages attached rather than using MAP_ANON
so that I can check the pages obtained from iov_iter_extract_pages()
without worrying about them changing due to swap, migrate, etc..
[?] Is this the best way to do things? Mirroring execve, it requires
a number of extra core symbols to be exported. Should this be done in
the core code?
(4) Add tests for copying into and out of UBUF and IOVEC iterators.
(5) Add tests for extracting pages from UBUF and IOVEC iterators.
(6) Add tests to benchmark copying 256MiB to UBUF, IOVEC, KVEC, BVEC and
XARRAY iterators.
(7) Add a test to benchmark copying 256MiB through dynamically allocated
256-page bvecs to simulate bio construction.
Example benchmarks output:
iov_kunit_benchmark_ubuf: avg 4474 uS, stddev 1340 uS
iov_kunit_benchmark_iovec: avg 6619 uS, stddev 23 uS
iov_kunit_benchmark_kvec: avg 2672 uS, stddev 14 uS
iov_kunit_benchmark_bvec: avg 3189 uS, stddev 19 uS
iov_kunit_benchmark_bvec_split: avg 3403 uS, stddev 8 uS
iov_kunit_benchmark_xarray: avg 3709 uS, stddev 7 uS
I've pushed the patches here also:
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?…
David
Changes
=======
ver #2)
- Use MAP_ANON to make the user buffer if we don't want a list of pages.
- KUNIT_ASSERT_NOT_ERR_OR_NULL() doesn't like __user pointers as the
condition, so cast.
- Make the UBUF benchmark loop, doing an iterator per page so that the
overhead from the iterator code is not negligible.
- Make the KVEC benchmark use an iovec per page so that the iteration is
not not negligible.
- Switch the benchmarking to use copy_from_iter() so that only a single
page is needed in the userspace buffer (as it can be shared R/O), not
256MiB's worth.
Link: https://lore.kernel.org/r/20230914221526.3153402-1-dhowells@redhat.com/ # v1
David Howells (9):
iov_iter: Fix some checkpatch complaints in kunit tests
iov_iter: Consolidate some of the repeated code into helpers
iov_iter: Consolidate the test vector struct in the kunit tests
iov_iter: Consolidate bvec pattern checking
iov_iter: Create a function to prepare userspace VM for UBUF/IOVEC
tests
iov_iter: Add copy kunit tests for ITER_UBUF and ITER_IOVEC
iov_iter: Add extract kunit tests for ITER_UBUF and ITER_IOVEC
iov_iter: Add benchmarking kunit tests
iov_iter: Add benchmarking kunit tests for UBUF/IOVEC
arch/loongarch/include/asm/page.h | 1 +
arch/s390/kernel/vdso.c | 1 +
fs/anon_inodes.c | 1 +
kernel/fork.c | 2 +
lib/kunit_iov_iter.c | 1241 ++++++++++++++++++++++++-----
mm/mmap.c | 1 +
mm/util.c | 3 +
7 files changed, 1058 insertions(+), 192 deletions(-)
Hi,
Here's a series that sets the speed attribute to slow on DRM tests that
are taking a while to execute.
With those patches, an initial run of the drm tests on arm64 were taking
59s to execute with:
$ ./tools/testing/kunit/kunit.py run \
--kunitconfig=drivers/gpu/drm/tests \
--arch arm64 \
--cross_compile aarch64-linux-gnu-
...
[11:50:07] Testing complete. Ran 340 tests: passed: 340
[11:50:07] Elapsed time: 62.261s total, 0.001s configuring, 2.703s building, 59.532s running
and are now taking 1.7s when filtering out the slow tests:
$ ./tools/testing/kunit/kunit.py run \
--kunitconfig=drivers/gpu/drm/tests \
--arch arm64 \
--cross_compile aarch64-linux-gnu- \
--filter "speed>slow"
...
[11:47:52] Testing complete. Ran 332 tests: passed: 332
[11:47:52] Elapsed time: 6.449s total, 0.001s configuring, 4.728s building, 1.678s running
Let me know what you think,
Maxime
Signed-off-by: Maxime Ripard <mripard(a)kernel.org>
---
Maxime Ripard (2):
kunit: Warn if tests are slow
drm/tests: Flag slow tests as such
drivers/gpu/drm/tests/drm_buddy_test.c | 2 +-
drivers/gpu/drm/tests/drm_mm_test.c | 14 +++++++-------
lib/kunit/test.c | 16 ++++++++++++++++
3 files changed, 24 insertions(+), 8 deletions(-)
---
base-commit: 0bb80ecc33a8fb5a682236443c1e740d5c917d1d
change-id: 20230911-kms-slow-tests-0261bee9a54b
Best regards,
--
Maxime Ripard <mripard(a)kernel.org>
The test_cases is not freed in kunit_free_suite_set().
And the copy pointer may be moved in kunit_filter_suites().
The filtered_suite and filtered_suite->test_cases allocated in the last
kunit_filter_attr_tests() in last inner for loop may be leaked if
kunit_filter_suites() fails.
If kunit_filter_suites() succeeds, not only copy but also filtered_suite
and filtered_suite->test_cases should be freed.
Jinjie Ruan (4):
kunit: Fix missed memory release in kunit_free_suite_set()
kunit: Fix the wrong kfree of copy for kunit_filter_suites()
kunit: Fix possible memory leak in kunit_filter_suites()
kunit: test: Fix the possible memory leak in executor_test
lib/kunit/executor.c | 23 +++++++++++++++++------
lib/kunit/executor_test.c | 24 ++++++++++++++++++------
2 files changed, 35 insertions(+), 12 deletions(-)
--
2.34.1
Hello!
Here is v6 of the mremap start address optimization / fix for exec warning.
Should be hopefully final now and only 2/7 and 6/7 need a tag. Thanks a lot to
Lorenzo and Linus for the detailed reviews.
Description of patches
======================
These patches optimizes the start addresses in move_page_tables() and tests the
changes. It addresses a warning [1] that occurs due to a downward, overlapping
move on a mutually-aligned offset within a PMD during exec. By initiating the
copy process at the PMD level when such alignment is present, we can prevent
this warning and speed up the copying process at the same time. Linus Torvalds
suggested this idea. Check the individual patches for more details.
[1] https://lore.kernel.org/all/ZB2GTBD%2FLWTrkOiO@dhcp22.suse.cz/
History of patches:
v5->v6:
1. Reworking the stack case a bit more and tested it (should be final now).
2. Other small nits.
v4->v5:
1. Rebased on mainline.
2. Several improvement suggestions from Lorenzo.
v3->v4:
1. Care to be taken to move purely within a VMA, in other words this check
in call_align_down():
if (vma->vm_start != addr_masked)
return false;
As an example of why this is needed:
Consider the following range which is 2MB aligned and is
a part of a larger 10MB range which is not shown. Each
character is 256KB below making the source and destination
2MB each. The lower case letters are moved (s to d) and the
upper case letters are not moved.
|DDDDddddSSSSssss|
If we align down 'ssss' to start from the 'SSSS', we will end up destroying
SSSS. The above if statement prevents that and I verified it.
I also added a test for this in the last patch.
2. Handle the stack case separately. We do not care about #1 for stack movement
because the 'SSSS' does not matter during this move. Further we need to do this
to prevent the stack move warning.
if (!for_stack && vma->vm_start <= addr_masked)
return false;
v2->v3:
1. Masked address was stored in int, fixed it to unsigned long to avoid truncation.
2. We now handle moves happening purely within a VMA, a new test is added to handle this.
3. More code comments.
v1->v2:
1. Trigger the optimization for mremaps smaller than a PMD. I tested by tracing
that it works correctly.
2. Fix issue with bogus return value found by Linus if we broke out of the
above loop for the first PMD itself.
v1: Initial RFC.
Joel Fernandes (1):
selftests: mm: Add a test for moving from an offset from start of
mapping
Joel Fernandes (Google) (6):
mm/mremap: Optimize the start addresses in move_page_tables()
mm/mremap: Allow moves within the same VMA for stack moves
selftests: mm: Fix failure case when new remap region was not found
selftests: mm: Add a test for mutually aligned moves > PMD size
selftests: mm: Add a test for remapping to area immediately after
existing mapping
selftests: mm: Add a test for remapping within a range
fs/exec.c | 2 +-
include/linux/mm.h | 2 +-
mm/mremap.c | 73 +++++-
tools/testing/selftests/mm/mremap_test.c | 301 +++++++++++++++++++----
4 files changed, 329 insertions(+), 49 deletions(-)
--
2.42.0.283.g2d96d420d3-goog
From c4e404036e0a7ffcaedc5760bee234713ccfe4a4 Mon Sep 17 00:00:00 2001
From: GuokaiXu <xuguokai(a)ucas.com.cn>
Date: Mon, 4 Sep 2023 10:18:04 +0800
Subject: [PATCH 1/1] Fix the spelling errors in comments
Signed-off-by: GuokaiXu <xuguokai(a)ucas.com.cn>
---
tools/testing/selftests/iommu/iommufd.c | 2 +-
tools/testing/selftests/iommu/iommufd_fail_nth.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/iommu/iommufd.c b/tools/testing/selftests/iommu/iommufd.c
index 33d08600be13..b7249ffc6750 100644
--- a/tools/testing/selftests/iommu/iommufd.c
+++ b/tools/testing/selftests/iommu/iommufd.c
@@ -1729,7 +1729,7 @@ TEST_F(vfio_compat_mock_domain, map)
ASSERT_EQ(0, ioctl(self->fd, VFIO_IOMMU_UNMAP_DMA, &unmap_cmd));
ASSERT_EQ(BUFFER_SIZE, unmap_cmd.size);
- /* UNMAP_FLAG_ALL requres 0 iova/size */
+ /* UNMAP_FLAG_ALL requires 0 iova/size */
ASSERT_EQ(0, ioctl(self->fd, VFIO_IOMMU_MAP_DMA, &map_cmd));
unmap_cmd.flags = VFIO_DMA_UNMAP_FLAG_ALL;
EXPECT_ERRNO(EINVAL, ioctl(self->fd, VFIO_IOMMU_UNMAP_DMA, &unmap_cmd));
diff --git a/tools/testing/selftests/iommu/iommufd_fail_nth.c b/tools/testing/selftests/iommu/iommufd_fail_nth.c
index a220ca2a689d..36e7aa4f615c 100644
--- a/tools/testing/selftests/iommu/iommufd_fail_nth.c
+++ b/tools/testing/selftests/iommu/iommufd_fail_nth.c
@@ -105,7 +105,7 @@ static bool fail_nth_next(struct __test_metadata *_metadata,
/*
* This is just an arbitrary limit based on the current kernel
- * situation. Changes in the kernel can dramtically change the number of
+ * situation. Changes in the kernel can dramatically change the number of
* required fault injection sites, so if this hits it doesn't
* necessarily mean a test failure, just that the limit has to be made
* bigger.
--
2.25.1