On 1/20/24 14:49, Charlie Jenkins wrote:
On Sat, Jan 20, 2024 at 02:13:14PM +0800, Yangyu Chen wrote:
Thanks for your reply.
On 1/20/24 09:34, Charlie Jenkins wrote:
On Sun, Jan 14, 2024 at 01:26:57AM +0800, Yangyu Chen wrote:
Hi, Charlie
Although this patchset has been merged I still hav
On Sat, Jan 20, 2024 at 02:13:14PM +0800, Yangyu Chen wrote:
> Thanks for your reply.
>
> On 1/20/24 09:34, Charlie Jenkins wrote:
> > On Sun, Jan 14, 2024 at 01:26:57AM +0800, Yangyu Chen wrote:
> > > Hi, Charlie
> > >
> > > Although this patchset has been merged I still have some questions abou
Thanks for your reply.
On 1/20/24 09:34, Charlie Jenkins wrote:
On Sun, Jan 14, 2024 at 01:26:57AM +0800, Yangyu Chen wrote:
Hi, Charlie
Although this patchset has been merged I still have some questions about
this patchset. Because it breaks regular mmap if address >= 38 bits on
sv48 / sv57 c
On Sun, Jan 14, 2024 at 01:26:57AM +0800, Yangyu Chen wrote:
> Hi, Charlie
>
> Although this patchset has been merged I still have some questions about
> this patchset. Because it breaks regular mmap if address >= 38 bits on
> sv48 / sv57 capable systems like qemu. For example, If a userspace prog
On Fri, Jan 19, 2024 at 3:35 PM Andrii Nakryiko
wrote:
>
> On Fri, Jan 19, 2024 at 3:13 PM Vincent Li wrote:
> >
> > On Fri, Jan 19, 2024 at 2:26 PM Alexei Starovoitov
> > wrote:
> > >
> > > On Fri, Jan 19, 2024 at 7:00 AM Vincent Li
> > > wrote:
> > > >
> > > > On Fri, Jan 19, 2024 at 4:23 AM
On Fri, Jan 19, 2024 at 3:13 PM Vincent Li wrote:
>
> On Fri, Jan 19, 2024 at 2:26 PM Alexei Starovoitov
> wrote:
> >
> > On Fri, Jan 19, 2024 at 7:00 AM Vincent Li wrote:
> > >
> > > On Fri, Jan 19, 2024 at 4:23 AM Eduard Zingerman
> > > wrote:
> > > >
> > > > On Fri, 2024-01-19 at 16:04 +080
On Fri, Jan 19, 2024 at 2:26 PM Alexei Starovoitov
wrote:
>
> On Fri, Jan 19, 2024 at 7:00 AM Vincent Li wrote:
> >
> > On Fri, Jan 19, 2024 at 4:23 AM Eduard Zingerman wrote:
> > >
> > > On Fri, 2024-01-19 at 16:04 +0800, Shung-Hsi Yu wrote:
> > >
> > > [...]
> > >
> > > > Final goal would be h
On Thu, Jan 18, 2024 at 03:26:43PM +, Mark Rutland wrote:
> On Tue, Jan 16, 2024 at 05:27:18PM -0800, Stephen Boyd wrote:
> > Quoting Mark Rutland (2024-01-16 03:51:14)
> > > Hi Stephen,
> > >
> > > On Fri, Jan 12, 2024 at 12:07:44PM -0800, Stephen Boyd wrote:
> > > > Call this function uncond
On Fri, 19 Jan 2024 21:07:19 + Simon Horman wrote:
> AFAIK this will only remove the first incidence of a comma.
> So I'm assuming this breaks with >64 CPUs.
Good point! I'll use ${var//,} in v2.
--
pw-bot: cr
On Fri, Jan 19, 2024 at 7:00 AM Vincent Li wrote:
>
> On Fri, Jan 19, 2024 at 4:23 AM Eduard Zingerman wrote:
> >
> > On Fri, 2024-01-19 at 16:04 +0800, Shung-Hsi Yu wrote:
> >
> > [...]
> >
> > > Final goal would be have BPF selftests compiled and test against our own
> > > kernel, without havin
On 2024-01-16 09:32 +0100, Paolo Abeni wrote:
> On Wed, 2024-01-10 at 09:14 -0500, Benjamin Poirier wrote:
> > The lib.sh script is meant to be sourced from other scripts, not executed
> > directly. Therefore, remove the executable bits from lib.sh's permissions.
>
> LGTM, but there is any special
On Fri, Jan 19, 2024 at 07:12:48AM -0800, Jakub Kicinski wrote:
> If there is more than 32 cpus the bitmask will start to contain
> commas, leading to:
>
> ./rps_default_mask.sh: line 36: [: ,: integer expression
> expected
>
> Remove the commas, bash doesn't interpret leading ze
In order for the page table level 5 to be in use, the CPU must have the
setting enabled in addition to the CONFIG option. Check for the flag to be
set to avoid false test failures on systems that do not have this cpu flag
set.
Signed-off-by: Audra Mitchell
---
tools/testing/selftests/mm/va_high_
On Fri, Jan 19, 2024 at 06:37:46PM +, Dmitry Safonov wrote:
> Hi Simon,
>
> On 1/19/24 16:25, Simon Horman wrote:
> > On Thu, Jan 18, 2024 at 02:51:36AM +, Dmitry Safonov wrote:
> >> Yeah, copy'n'paste typo.
> >>
> >> Fixes: 3c3ead555648 ("selftests/net: Add TCP-AO key-management test")
>
On 1/18/24 17:13, Jakub Kicinski wrote:
> On Thu, 18 Jan 2024 17:04:25 + Dmitry Safonov wrote:
>>> Somewhat unrelated to these fixes but related to the tcp_ao selftests
>>> in general - could you please also add a config file so that it's
>>> easy to build a minimal kernel for running the tests
Hi Simon,
On 1/19/24 16:25, Simon Horman wrote:
> On Thu, Jan 18, 2024 at 02:51:36AM +, Dmitry Safonov wrote:
>> Yeah, copy'n'paste typo.
>>
>> Fixes: 3c3ead555648 ("selftests/net: Add TCP-AO key-management test")
>> Reported-by: Nassiri, Mohammad
>> Closes:
>> https://lore.kernel.org/all/dm
Hi Simon,
On 1/19/24 16:26, Simon Horman wrote:
> On Thu, Jan 18, 2024 at 02:51:34AM +, Dmitry Safonov wrote:
>> From: Mohammad Nassiri
>>
>> The end_server() function only operates in the server thread
>> and always takes an accept socket instead of a listen socket as
>> its input argument.
On Thu, Jan 18, 2024 at 4:14 PM Kyle Huey wrote:
>
Acked-by: Song Liu
with a couple nitpicks below.
[...]
> +int sigio_count, sigtrap_count;
> +
> +static void handle_sigio(int sig __always_unused)
> +{
> + ++sigio_count;
> +}
> +
> +static void handle_sigtrap(int signum __always_unused,
Hi Maciej,
On 1/18/2024 11:37 PM, Maciej Wieczór-Retman wrote:
> On 2024-01-18 at 09:15:46 -0800, Reinette Chatre wrote:
>> On 1/18/2024 4:02 AM, Maciej Wieczór-Retman wrote:
>>> On 2024-01-17 at 10:49:06 -0800, Reinette Chatre wrote:
On 1/17/2024 12:26 AM, Maciej Wieczór-Retman wrote:
>
On Thu, Jan 18, 2024 at 02:51:34AM +, Dmitry Safonov wrote:
> From: Mohammad Nassiri
>
> The end_server() function only operates in the server thread
> and always takes an accept socket instead of a listen socket as
> its input argument. To align with this, invert the boolean values
> used wh
On Thu, Jan 18, 2024 at 02:51:36AM +, Dmitry Safonov wrote:
> Yeah, copy'n'paste typo.
>
> Fixes: 3c3ead555648 ("selftests/net: Add TCP-AO key-management test")
> Reported-by: Nassiri, Mohammad
> Closes:
> https://lore.kernel.org/all/dm6pr04mb4202bc58a9fd5bdd24a16e8ec5...@dm6pr04mb4202.nampr
Hi Muhammad,
Afraid this patch is causing a regression on our CI system when it turned up in
linux-next today. Additionally, 2 of thetests you have added are failing because
the scripts are not exported correctly...
On 16/01/2024 09:06, Muhammad Usama Anjum wrote:
> Add missing tests to run_vmtes
If there is more than 32 cpus the bitmask will start to contain
commas, leading to:
./rps_default_mask.sh: line 36: [: ,: integer expression
expected
Remove the commas, bash doesn't interpret leading zeroes as oct
so that should be good enough.
Fixes: c12e0d5f267d ("self-tests:
On Fri, Jan 19, 2024 at 4:23 AM Eduard Zingerman wrote:
>
> On Fri, 2024-01-19 at 16:04 +0800, Shung-Hsi Yu wrote:
>
> [...]
>
> > Final goal would be have BPF selftests compiled and test against our own
> > kernel, without having to come up with a specific kernel flavor that is
> > used to build
> May I take the liberty to ask why I don't see patch applied to above branch?
Just wasn't pushed yet. It is now.
On Fri, Jan 19, 2024 at 02:11:01PM +0100, Alexander Gordeev wrote:
> FWIW, for s390 part:
>
> Alexander Gordeev
Acked-by: Alexander Gordeev
On systems with 64k page size and 512M huge page sizes, the allocation
and test succeeds but errors out at the munmap. As the comment states,
munmap will failure if its not HUGEPAGE aligned. This is due to the
length of the mapping being 1/2 the size of the hugepage causing the
munmap to not be hug
NACK.
I accidentally sent an older version of this patch. Following up with V2.
On Fri, Jan 19, 2024 at 5:58 AM Nico Pache wrote:
>
> On systems with 64k page size and 512M huge page sizes, the allocation
> and test succeeds but errors out at the munmap. As the comment states,
> munmap will fail
On Fri, Jan 12, 2024 at 02:43:51PM -0300, Marcos Paulo de Souza wrote:
Hi Marcos,
...
> arch/s390/configs/debug_defconfig | 1 -
> arch/s390/configs/defconfig| 1 -
> lib/Kconfig.debug | 22 --
...
> diff --git a/ar
On systems with 64k page size and 512M huge page sizes, the allocation
and test succeeds but errors out at the munmap. As the comment states,
munmap will failure if its not HUGEPAGE aligned. This is due to the
length of the mapping being 1/2 the size of the hugepage causing the
munmap to not be hug
On Mon, Jan 15, 2024 at 06:24:09PM +0800, Hu Yadi wrote:
> From: "Hu.Yadi"
>
> Two issues comes up while building selftest/landlock on my side
> (gcc 7.3/glibc-2.28/kernel-4.19)
>
> the first one is as to gettid
>
> net_test.c: In function ‘set_service’:
> net_test.c:91:45: warning: implicit de
Thank you, this is really nice!
Only tiny style nitpicks here.
Reviewed-by: G�nther Noack
On Thu, Jan 18, 2024 at 12:36:32PM +0100, Micka�l Sala�n wrote:
> Add the SECURITY_LANDLOCK_KUNIT_TEST option to enable KUnit tests for
> Landlock. The minimal required configuration is listed in th
On Fri, 2024-01-19 at 16:04 +0800, Shung-Hsi Yu wrote:
[...]
> Final goal would be have BPF selftests compiled and test against our own
> kernel, without having to come up with a specific kernel flavor that is
> used to build and run the selftest. For v5.14 and v5.19-based kernel it
> works: comp
On Wed, Jan 17, 2024 at 11:35:03AM -0500, Waiman Long wrote:
> This patch series is based on the RFC patch from Frederic [1]. Instead
> of offering RCU_NOCB as a separate option, it is now lumped into a
> root-only cpuset.cpus.isolation_full flag that will enable all the
> additional CPU isolation
On 2024/1/18 21:38, Jason Gunthorpe wrote:
On Thu, Jan 18, 2024 at 05:28:01PM +0800, Yi Liu wrote:
On 2024/1/17 20:56, Jason Gunthorpe wrote:
On Wed, Jan 17, 2024 at 04:24:24PM +0800, Yi Liu wrote:
Above indeed makes more sense if there can be concurrent attach/replace/detach
on a single pasid
amd-pstate driver support enable/disable preferred core.
Default enabled on platforms supporting amd-pstate preferred core.
Disable amd-pstate preferred core with
"amd_prefcore=disable" added to the kernel command line.
Signed-off-by: Meng Li
Reviewed-by: Mario Limonciello
Reviewed-by: Wyes Karn
Introduce amd-pstate preferred core.
check preferred core state set by the kernel parameter:
$ cat /sys/devices/system/cpu/amd-pstate/prefcore
Tested-by: Oleksandr Natalenko
Reviewed-by: Wyes Karny
Reviewed-by: Mario Limonciello
Reviewed-by: Huang Rui
Reviewed-by: Perry Yuan
Signed-off-by: M
Preferred core rankings can be changed dynamically by the
platform based on the workload and platform conditions and
accounting for thermals and aging.
When this occurs, cpu priority need to be set.
Tested-by: Oleksandr Natalenko
Reviewed-by: Mario Limonciello
Reviewed-by: Wyes Karny
Reviewed-b
BIOS issues the notify 0x85 to OS that the highest performance
changed. And it will affect the ranking of the preferred core.
AMD-pstate driver will set the priority of cores based on the
preferred core ranking.
Tested-by: Oleksandr Natalenko
Reviewed-by: Mario Limonciello
Reviewed-by: Huang Rui
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 preferrred core.
Here sched_set_itmt_core_prio() is called to set priori
Add support for getting the highest performance to the
generic CPPC driver. This enables downstream drivers
such as amd-pstate to discover and use these values.
Please refer to Chapter 8.4.6.1.1.1. Highest Performance
of ACPI Specification 6.5 for details on continuous
performance control of CPPC.
amd-pstate driver also uses SCHED_MC_PRIO, so decouple the requirement
of CPU_SUP_INTEL from the dependencies to allow compilation in kernels
without Intel CPU support.
Tested-by: Oleksandr Natalenko
Reviewed-by: Mario Limonciello
Reviewed-by: Huang Rui
Reviewed-by: Perry Yuan
Signed-off-by: M
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
On Thu, Jan 18, 2024 at 05:58:20PM +0200, Eduard Zingerman wrote:
> On Thu, 2024-01-18 at 19:58 +0800, Shung-Hsi Yu wrote:
> > Compilation of lsm_cgroup.c will fail if the vmlinux.h comes from a
> > kernel that does _not_ have CONFIG_PACKET=y. The reason is that the
> > definition of struct sockadd
44 matches
Mail list logo
