On Mon 06-08-18 08:42:02, syzbot wrote:
> Hello,
>
> syzbot has tested the proposed patch but the reproducer still triggered
> crash:
> WARNING in try_charge
>
> Killed process 6410 (syz-executor5) total-vm:37708kB, anon-rss:2128kB,
> file-rss:0kB, shmem-rss:0kB
> oom_reaper: reaped process 6410
On Mon 06-08-18 08:42:02, syzbot wrote:
> Hello,
>
> syzbot has tested the proposed patch but the reproducer still triggered
> crash:
> WARNING in try_charge
>
> Killed process 6410 (syz-executor5) total-vm:37708kB, anon-rss:2128kB,
> file-rss:0kB, shmem-rss:0kB
> oom_reaper: reaped process 6410
Hello,
On Mon, Aug 06, 2018 at 01:44:49PM +0200, Paolo Bonzini wrote:
> On 06/08/2018 09:51, Xiao Guangrong wrote:
> >
> >
> > On 07/27/2018 11:46 PM, Paolo Bonzini wrote:
> >> We are currently cutting hva_to_pfn_fast short if we do not want an
> >> immediate exit, which is represented by
Hello,
On Mon, Aug 06, 2018 at 01:44:49PM +0200, Paolo Bonzini wrote:
> On 06/08/2018 09:51, Xiao Guangrong wrote:
> >
> >
> > On 07/27/2018 11:46 PM, Paolo Bonzini wrote:
> >> We are currently cutting hva_to_pfn_fast short if we do not want an
> >> immediate exit, which is represented by
Hello, David,
So I have updated rcutorture to include need_resched()-protected calls to
cond_resched() in a tight loop that includes an RCU read-side critical
section on each pass. This loop runs for five seconds by default and
complains bitterly if grace periods did not complete during that
Hello, David,
So I have updated rcutorture to include need_resched()-protected calls to
cond_resched() in a tight loop that includes an RCU read-side critical
section on each pass. This loop runs for five seconds by default and
complains bitterly if grace periods did not complete during that
On Mon, Aug 06, 2018 at 10:10:47AM -0700, Stephen Boyd wrote:
> Now that the /firmware/coreboot node in DT is populated by the core DT
> platform code with commit 3aa0582fdb82 ("of: platform: populate
> /firmware/ node from of_platform_default_populate_init()") we should and
Does this deserve a
On Mon, Aug 06, 2018 at 10:10:47AM -0700, Stephen Boyd wrote:
> Now that the /firmware/coreboot node in DT is populated by the core DT
> platform code with commit 3aa0582fdb82 ("of: platform: populate
> /firmware/ node from of_platform_default_populate_init()") we should and
Does this deserve a
Stephen Rothwell writes:
> Hi all,
>
> On Wed, 20 Jun 2018 12:39:05 +1000 Stephen Rothwell
> wrote:
>
> Are there any comments on this resolution. I just had to do it all
> again due to slight changes in the vfs tree. What are you guys going
> to tell Linus when he comes to merge this?
Stephen Rothwell writes:
> Hi all,
>
> On Wed, 20 Jun 2018 12:39:05 +1000 Stephen Rothwell
> wrote:
>
> Are there any comments on this resolution. I just had to do it all
> again due to slight changes in the vfs tree. What are you guys going
> to tell Linus when he comes to merge this?
On Mon 06-08-18 16:58:01, Dmitry Vyukov wrote:
> On Mon, Aug 6, 2018 at 4:21 PM, Michal Hocko wrote:
> > On Mon 06-08-18 13:57:38, Dmitry Vyukov wrote:
> >> On Mon, Aug 6, 2018 at 1:02 PM, Michal Hocko wrote:
> > [...]
> >> >> A much
> >> >> friendlier for user way to say this would be print a
On Mon 06-08-18 16:58:01, Dmitry Vyukov wrote:
> On Mon, Aug 6, 2018 at 4:21 PM, Michal Hocko wrote:
> > On Mon 06-08-18 13:57:38, Dmitry Vyukov wrote:
> >> On Mon, Aug 6, 2018 at 1:02 PM, Michal Hocko wrote:
> > [...]
> >> >> A much
> >> >> friendlier for user way to say this would be print a
David Howells writes:
>
> (*) FSCONFIG_CMD_CREATE: Trigger superblock creation.
>
> (*) FSCONFIG_CMD_RECONFIGURE: Trigger superblock reconfiguration.
>
First let me thank you for adding both FSCONFIG_CMD_CREATE and
FSCONFIG_CMD_RECONFIGURE. Unfortunately the implementation is currently
David Howells writes:
>
> (*) FSCONFIG_CMD_CREATE: Trigger superblock creation.
>
> (*) FSCONFIG_CMD_RECONFIGURE: Trigger superblock reconfiguration.
>
First let me thank you for adding both FSCONFIG_CMD_CREATE and
FSCONFIG_CMD_RECONFIGURE. Unfortunately the implementation is currently
From: Kan Liang
A ucode patch is needed for Goldmont Plus while counter freezing feature
is enabled. Otherwise, there will be some issues, e.g. PMI flood with
some events.
Add a quirk to check microcode version. Only enable counter freezing
feature on the machine with ucode patch.
From: Kan Liang
A ucode patch is needed for Goldmont Plus while counter freezing feature
is enabled. Otherwise, there will be some issues, e.g. PMI flood with
some events.
Add a quirk to check microcode version. Only enable counter freezing
feature on the machine with ucode patch.
From: Kan Liang
The Arch Perfmon v4 PMI handler is substantially different than
the older PMI handler. Instead of adding more and more ifs cleanly
fork the new handler into a new function, with the main common
code factored out into a common function.
Fix complaint from checkpatch.pl by
From: Kan Liang
The Arch Perfmon v4 PMI handler is substantially different than
the older PMI handler. Instead of adding more and more ifs cleanly
fork the new handler into a new function, with the main common
code factored out into a common function.
Fix complaint from checkpatch.pl by
From: Andi Kleen
Implements counter freezing for Arch Perfmon v4 (Skylake and
newer). This allows to speed up the PMI handler by avoiding
unnecessary MSR writes and make it more accurate.
The Arch Perfmon v4 PMI handler is substantially different than
the older PMI handler.
Differences to the
From: Andi Kleen
Implements counter freezing for Arch Perfmon v4 (Skylake and
newer). This allows to speed up the PMI handler by avoiding
unnecessary MSR writes and make it more accurate.
The Arch Perfmon v4 PMI handler is substantially different than
the older PMI handler.
Differences to the
On 08/06/2018 11:42 AM, Joe Perches wrote:
> On Mon, 2018-08-06 at 16:41 +, David Laight wrote:
>> From: Andy Shevchenko
>>> Sent: 05 August 2018 11:26
>>>
>>> On Sun, Aug 5, 2018 at 3:18 AM, Gustavo A. R. Silva
>>> wrote:
Return statements in functions returning bool should use true
Hello,
On Mon, Aug 06, 2018 at 09:30:15AM +1000, Stephen Rothwell wrote:
> > > So this issue is still happening as of next-20180702. Can you guys
> > > please revert the commit above while working on a better solution?
> >
> > That's fine with me. I'm not very familiar with the process here,
On 08/06/2018 11:42 AM, Joe Perches wrote:
> On Mon, 2018-08-06 at 16:41 +, David Laight wrote:
>> From: Andy Shevchenko
>>> Sent: 05 August 2018 11:26
>>>
>>> On Sun, Aug 5, 2018 at 3:18 AM, Gustavo A. R. Silva
>>> wrote:
Return statements in functions returning bool should use true
Hello,
On Mon, Aug 06, 2018 at 09:30:15AM +1000, Stephen Rothwell wrote:
> > > So this issue is still happening as of next-20180702. Can you guys
> > > please revert the commit above while working on a better solution?
> >
> > That's fine with me. I'm not very familiar with the process here,
On Mon, Aug 6, 2018 at 6:13 PM Stephen Boyd wrote:
>
> Now that the /firmware/coreboot node in DT is populated by the core DT
> platform code with commit 3aa0582fdb82 ("of: platform: populate
> /firmware/ node from of_platform_default_populate_init()") we should and
> can remove the platform
On Mon, Aug 6, 2018 at 6:13 PM Stephen Boyd wrote:
>
> Now that the /firmware/coreboot node in DT is populated by the core DT
> platform code with commit 3aa0582fdb82 ("of: platform: populate
> /firmware/ node from of_platform_default_populate_init()") we should and
> can remove the platform
On 6 August 2018 at 19:09, Mikulas Patocka wrote:
>
>
> On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
>
>> On 6 August 2018 at 14:42, Robin Murphy wrote:
>> > On 06/08/18 11:25, Mikulas Patocka wrote:
>> > [...]
>> >>>
>> >>> None of this explains why some transactions fail to make it across
>> >>>
On 6 August 2018 at 19:09, Mikulas Patocka wrote:
>
>
> On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
>
>> On 6 August 2018 at 14:42, Robin Murphy wrote:
>> > On 06/08/18 11:25, Mikulas Patocka wrote:
>> > [...]
>> >>>
>> >>> None of this explains why some transactions fail to make it across
>> >>>
On Mon, 6 Aug 2018, Catalin Marinas wrote:
> On Mon, Aug 06, 2018 at 05:47:36PM +0200, Ard Biesheuvel wrote:
> > On 6 August 2018 at 14:42, Robin Murphy wrote:
> > > On 06/08/18 11:25, Mikulas Patocka wrote:
> > > [...]
> > >>>
> > >>> None of this explains why some transactions fail to make
On Mon, 6 Aug 2018, Catalin Marinas wrote:
> On Mon, Aug 06, 2018 at 05:47:36PM +0200, Ard Biesheuvel wrote:
> > On 6 August 2018 at 14:42, Robin Murphy wrote:
> > > On 06/08/18 11:25, Mikulas Patocka wrote:
> > > [...]
> > >>>
> > >>> None of this explains why some transactions fail to make
On Mon, Aug 06, 2018 at 05:47:36PM +0200, Ard Biesheuvel wrote:
> On 6 August 2018 at 14:42, Robin Murphy wrote:
> > On 06/08/18 11:25, Mikulas Patocka wrote:
> > [...]
> >>>
> >>> None of this explains why some transactions fail to make it across
> >>> entirely. The overlapping writes in
On Mon, Aug 06, 2018 at 05:47:36PM +0200, Ard Biesheuvel wrote:
> On 6 August 2018 at 14:42, Robin Murphy wrote:
> > On 06/08/18 11:25, Mikulas Patocka wrote:
> > [...]
> >>>
> >>> None of this explains why some transactions fail to make it across
> >>> entirely. The overlapping writes in
Now that the /firmware/coreboot node in DT is populated by the core DT
platform code with commit 3aa0582fdb82 ("of: platform: populate
/firmware/ node from of_platform_default_populate_init()") we should and
can remove the platform device creation here. Otherwise, the
of_platform_device_create()
Now that the /firmware/coreboot node in DT is populated by the core DT
platform code with commit 3aa0582fdb82 ("of: platform: populate
/firmware/ node from of_platform_default_populate_init()") we should and
can remove the platform device creation here. Otherwise, the
of_platform_device_create()
On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
> On 6 August 2018 at 14:42, Robin Murphy wrote:
> > On 06/08/18 11:25, Mikulas Patocka wrote:
> > [...]
> >>>
> >>> None of this explains why some transactions fail to make it across
> >>> entirely. The overlapping writes in question write the same
On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
> On 6 August 2018 at 14:42, Robin Murphy wrote:
> > On 06/08/18 11:25, Mikulas Patocka wrote:
> > [...]
> >>>
> >>> None of this explains why some transactions fail to make it across
> >>> entirely. The overlapping writes in question write the same
Add SPDX-License-Identifier to the source files
Signed-off-by: Arkadiusz Lis
---
drivers/staging/olpc_dcon/olpc_dcon.c| 1 +
drivers/staging/olpc_dcon/olpc_dcon_xo_1.c | 1 +
drivers/staging/olpc_dcon/olpc_dcon_xo_1_5.c | 1 +
3 files changed, 3 insertions(+)
diff --git
Add SPDX-License-Identifier to the source files
Signed-off-by: Arkadiusz Lis
---
drivers/staging/olpc_dcon/olpc_dcon.c| 1 +
drivers/staging/olpc_dcon/olpc_dcon_xo_1.c | 1 +
drivers/staging/olpc_dcon/olpc_dcon_xo_1_5.c | 1 +
3 files changed, 3 insertions(+)
diff --git
On Thu, Oct 05, 2017 at 06:31:29PM -0700, Linus Torvalds wrote:
> On Thu, Oct 5, 2017 at 4:06 PM, Al Viro wrote:
> >
> > Just to make sure we are on the same page: out of kstatfs fields
> > we have 5 u64 ones (see above; all of them are u64 is struct statfs64
> > on all architectures), an opaque
On Thu, Oct 05, 2017 at 06:31:29PM -0700, Linus Torvalds wrote:
> On Thu, Oct 5, 2017 at 4:06 PM, Al Viro wrote:
> >
> > Just to make sure we are on the same page: out of kstatfs fields
> > we have 5 u64 ones (see above; all of them are u64 is struct statfs64
> > on all architectures), an opaque
On 06/08/2018 10:17, Liu, Jingqi wrote:
> Hi Paolo,
>
> Do you have any comments for the series ?
> Thanks
> Jingqi
Hi,
the features are not yet available in Linus's tree, so I have to wait
before including this series.
Paolo
On 06/08/2018 10:17, Liu, Jingqi wrote:
> Hi Paolo,
>
> Do you have any comments for the series ?
> Thanks
> Jingqi
Hi,
the features are not yet available in Linus's tree, so I have to wait
before including this series.
Paolo
On Mon, Aug 6, 2018 at 8:42 AM Peter Zijlstra wrote:
>
> On Mon, Aug 06, 2018 at 08:35:07AM -0700, Fubo Chen wrote:
> > On Thu, Jul 19, 2018 at 2:21 PM Peter Zijlstra wrote:
> > > --- a/include/uapi/linux/perf_event.h
> > > +++ b/include/uapi/linux/perf_event.h
> > > @@ -143,6 +143,8 @@ enum
On Mon, Aug 6, 2018 at 8:42 AM Peter Zijlstra wrote:
>
> On Mon, Aug 06, 2018 at 08:35:07AM -0700, Fubo Chen wrote:
> > On Thu, Jul 19, 2018 at 2:21 PM Peter Zijlstra wrote:
> > > --- a/include/uapi/linux/perf_event.h
> > > +++ b/include/uapi/linux/perf_event.h
> > > @@ -143,6 +143,8 @@ enum
On 8/6/18 6:26 AM, Michal Hocko wrote:
On Fri 03-08-18 13:47:19, Yang Shi wrote:
On 8/3/18 1:53 AM, Michal Hocko wrote:
On Fri 27-07-18 02:10:13, Yang Shi wrote:
Introduces three new helper functions:
* munmap_addr_sanity()
* munmap_lookup_vma()
* munmap_mlock_vma()
They will
On 8/6/18 6:26 AM, Michal Hocko wrote:
On Fri 03-08-18 13:47:19, Yang Shi wrote:
On 8/3/18 1:53 AM, Michal Hocko wrote:
On Fri 27-07-18 02:10:13, Yang Shi wrote:
Introduces three new helper functions:
* munmap_addr_sanity()
* munmap_lookup_vma()
* munmap_mlock_vma()
They will
From: Colin Ian King
The allocation of lmac->dmacs is not being checked for allocation
failure. Add the check.
Fixes: 3a34ecfd9d3f ("net: thunderx: add MAC address filter tracking for LMAC")
Signed-off-by: Colin Ian King
---
drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 2 ++
1 file
From: Colin Ian King
The allocation of lmac->dmacs is not being checked for allocation
failure. Add the check.
Fixes: 3a34ecfd9d3f ("net: thunderx: add MAC address filter tracking for LMAC")
Signed-off-by: Colin Ian King
---
drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 2 ++
1 file
Hi,
On 08/06/2018 09:39 AM, Patrick Bellasi wrote:
> diff --git a/init/Kconfig b/init/Kconfig
> index 041f3a022122..1d45a6877d6f 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -583,6 +583,25 @@ config HAVE_UNSTABLE_SCHED_CLOCK
> config GENERIC_SCHED_CLOCK
> bool
>
> +menu
Hi,
On 08/06/2018 09:39 AM, Patrick Bellasi wrote:
> diff --git a/init/Kconfig b/init/Kconfig
> index 041f3a022122..1d45a6877d6f 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -583,6 +583,25 @@ config HAVE_UNSTABLE_SCHED_CLOCK
> config GENERIC_SCHED_CLOCK
> bool
>
> +menu
On Mon, 2018-08-06 at 10:30 +0200, Rafael J. Wysocki wrote:
> On Sat, Aug 4, 2018 at 7:31 PM, Gabriele Mazzotta
> wrote:
> > On 04/08/2018 17:29, Gabriele Mazzotta wrote:
> > > This change does not take into account that some BIOSes change
> > > MSR_IA32_MISC_ENABLE_TURBO_DISABLE depending on the
On Mon, 2018-08-06 at 10:30 +0200, Rafael J. Wysocki wrote:
> On Sat, Aug 4, 2018 at 7:31 PM, Gabriele Mazzotta
> wrote:
> > On 04/08/2018 17:29, Gabriele Mazzotta wrote:
> > > This change does not take into account that some BIOSes change
> > > MSR_IA32_MISC_ENABLE_TURBO_DISABLE depending on the
Am Montag, den 06.08.2018, 02:34 + schrieb Robin Gong:
> > > > Not all boards follow the reference design, that's a fact of
> > > > life.
> > > >
> > > > Please look at the i.MX6Q reference manual. The sequence
> > > > implemented
> > > > in this patchset can be found as a valid way to power
On Mon, Aug 6, 2018 at 1:31 AM Christoph Hellwig wrote:
>
> As our dear leader didn't like the ->poll_mask method this tries to
> implement the behavior using plain old ->poll which is rather painful.
I'm not seeing what's painful for this. Looking at the patches, this
is *much* more
Am Montag, den 06.08.2018, 02:34 + schrieb Robin Gong:
> > > > Not all boards follow the reference design, that's a fact of
> > > > life.
> > > >
> > > > Please look at the i.MX6Q reference manual. The sequence
> > > > implemented
> > > > in this patchset can be found as a valid way to power
On Mon, Aug 6, 2018 at 1:31 AM Christoph Hellwig wrote:
>
> As our dear leader didn't like the ->poll_mask method this tries to
> implement the behavior using plain old ->poll which is rather painful.
I'm not seeing what's painful for this. Looking at the patches, this
is *much* more
On 8/6/18 2:40 AM, Michal Hocko wrote:
On Fri 03-08-18 14:01:58, Yang Shi wrote:
On 8/3/18 2:07 AM, Michal Hocko wrote:
On Fri 27-07-18 02:10:14, Yang Shi wrote:
When running some mmap/munmap scalability tests with large memory (i.e.
300GB), the below hung task issue may happen
On 8/6/18 2:40 AM, Michal Hocko wrote:
On Fri 03-08-18 14:01:58, Yang Shi wrote:
On 8/3/18 2:07 AM, Michal Hocko wrote:
On Fri 27-07-18 02:10:14, Yang Shi wrote:
When running some mmap/munmap scalability tests with large memory (i.e.
300GB), the below hung task issue may happen
On Fri 29 Jun 03:20 PDT 2018, Rajendra Nayak wrote:
> With rpmh ARC resources being modelled as power domains with
> performance state, add support to proxy vote on these for SDM845.
> Add support to vote on multiple of them, now that genpd supports
> associating multiple power domains to a
On Fri 29 Jun 03:20 PDT 2018, Rajendra Nayak wrote:
> With rpmh ARC resources being modelled as power domains with
> performance state, add support to proxy vote on these for SDM845.
> Add support to vote on multiple of them, now that genpd supports
> associating multiple power domains to a
On Sun, 5 Aug 2018 20:44:37 -0700
"Joel Fernandes (Google)" wrote:
> Commit f37755490fe9 ("tracepoints: Do not trace when cpu is offline")
> causes a problem for lockdep using tracepoint code. Once a CPU is
> offline, tracepoints donot get called, however this causes a big problem
> for lockdep
On Sun, 5 Aug 2018 20:44:37 -0700
"Joel Fernandes (Google)" wrote:
> Commit f37755490fe9 ("tracepoints: Do not trace when cpu is offline")
> causes a problem for lockdep using tracepoint code. Once a CPU is
> offline, tracepoints donot get called, however this causes a big problem
> for lockdep
On the error path of mxs_auart_request_gpio_irq() is performed
backward iterating with index i of enum type. Underline enum type
may be unsigned char. In this case check (--i >= 0) will be always
true and error handling goes into infinite loop.
The patch changes type of index variable to int.
On the error path of mxs_auart_request_gpio_irq() is performed
backward iterating with index i of enum type. Underline enum type
may be unsigned char. In this case check (--i >= 0) will be always
true and error handling goes into infinite loop.
The patch changes type of index variable to int.
In order to properly support hierarchical resources control, the cgroup
delegation model requires that attribute writes from a child group never
fail but still are (potentially) constrained based on parent's assigned
resources. This requires to properly propagate and aggregate parent
attributes
In order to properly support hierarchical resources control, the cgroup
delegation model requires that attribute writes from a child group never
fail but still are (potentially) constrained based on parent's assigned
resources. This requires to properly propagate and aggregate parent
attributes
The cgroup's CPU controller allows to assign a specified (maximum)
bandwidth to the tasks of a group. However this bandwidth is defined and
enforced only on a temporal base, without considering the actual
frequency a CPU is running on. Thus, the amount of computation completed
by a task within an
mm/gup.c provides a kernel interface that accepts user addresses and
manipulates user pages directly (for example get_user_pages, that is used
by the futex syscall). Since a user can provided tagged addresses, we need
to handle such case.
Add untagging to gup.c functions that use user addresses
mm/gup.c provides a kernel interface that accepts user addresses and
manipulates user pages directly (for example get_user_pages, that is used
by the futex syscall). Since a user can provided tagged addresses, we need
to handle such case.
Add untagging to gup.c functions that use user addresses
The cgroup's CPU controller allows to assign a specified (maximum)
bandwidth to the tasks of a group. However this bandwidth is defined and
enforced only on a temporal base, without considering the actual
frequency a CPU is running on. Thus, the amount of computation completed
by a task within an
On Mon, 2018-08-06 at 16:41 +, David Laight wrote:
> From: Andy Shevchenko
> > Sent: 05 August 2018 11:26
> >
> > On Sun, Aug 5, 2018 at 3:18 AM, Gustavo A. R. Silva
> > wrote:
> > > Return statements in functions returning bool should use true or false
> > > instead of an integer value.
> >
On Mon, 2018-08-06 at 16:41 +, David Laight wrote:
> From: Andy Shevchenko
> > Sent: 05 August 2018 11:26
> >
> > On Sun, Aug 5, 2018 at 3:18 AM, Gustavo A. R. Silva
> > wrote:
> > > Return statements in functions returning bool should use true or false
> > > instead of an integer value.
> >
Utilization clamping requires to map each different clamp value
into one of the available clamp groups used by the scheduler's fast-path
to account for RUNNABLE tasks. Thus, each time a TG's clamp value is
updated we need to get a reference to the new value's clamp group and
release a reference to
Utilization clamping requires to map each different clamp value
into one of the available clamp groups used by the scheduler's fast-path
to account for RUNNABLE tasks. Thus, each time a TG's clamp value is
updated we need to get a reference to the new value's clamp group and
release a reference to
Clamp values cannot be tuned at the root cgroup level. Moreover, because
of the delegation model requirements and how the parent clamps
propagation works, if we want to enable subgroups to set a non null
util.min, we need to be able to configure the root group util.min to the
allow the maximum
Add a note that work on passing tagged user pointers to the kernel via
syscalls has started, but might not be complete yet.
Signed-off-by: Andrey Konovalov
---
Documentation/arm64/tagged-pointers.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
Clamp values cannot be tuned at the root cgroup level. Moreover, because
of the delegation model requirements and how the parent clamps
propagation works, if we want to enable subgroups to set a non null
util.min, we need to be able to configure the root group util.min to the
allow the maximum
Add a note that work on passing tagged user pointers to the kernel via
syscalls has started, but might not be complete yet.
Signed-off-by: Andrey Konovalov
---
Documentation/arm64/tagged-pointers.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
When a task group refcounts a new clamp group, we need to ensure that
the new clamp values are immediately enforced to all its tasks which are
currently RUNNABLE. This is to ensure that all currently RUNNABLE tasks
are boosted and/or clamped as requested as soon as possible.
Let's ensure that,
When a task group refcounts a new clamp group, we need to ensure that
the new clamp values are immediately enforced to all its tasks which are
currently RUNNABLE. This is to ensure that all currently RUNNABLE tasks
are boosted and/or clamped as requested as soon as possible.
Let's ensure that,
devio allows to mmap memory regions and keeps them in a list. It also
accepts a user address through an ioctl call and searches the memory
region list for the region that contains this address. Since the addresses
provided to mmap must not be tagged, and the addresses provided to ioctl
might be
Utilization clamping requires each CPU to know which clamp values are
assigned to tasks that are currently RUNNABLE on that CPU.
Multiple tasks can be assigned the same clamp value and tasks with
different clamp values can be concurrently active on the same CPU.
Thus, a proper data structure is
When a util_max clamped task sleeps, its clamp constraints are removed
from the CPU. However, the blocked utilization on that CPU can still be
higher than the max clamp value enforced while that task was running.
This max clamp removal when a CPU is going to be idle could thus allow
unwanted CPU
devio allows to mmap memory regions and keeps them in a list. It also
accepts a user address through an ioctl call and searches the memory
region list for the region that contains this address. Since the addresses
provided to mmap must not be tagged, and the addresses provided to ioctl
might be
Utilization clamping requires each CPU to know which clamp values are
assigned to tasks that are currently RUNNABLE on that CPU.
Multiple tasks can be assigned the same clamp value and tasks with
different clamp values can be concurrently active on the same CPU.
Thus, a proper data structure is
When a util_max clamped task sleeps, its clamp constraints are removed
from the CPU. However, the blocked utilization on that CPU can still be
higher than the max clamp value enforced while that task was running.
This max clamp removal when a CPU is going to be idle could thus allow
unwanted CPU
Utilization clamp values enforced on a CPU by a task can be updated at
run-time, for example via a sched_setattr syscall, while a task is
currently RUNNABLE on that CPU. In these cases, the task can be already
refcounting a clamp group for its CPU and thus we need to update this
reference to
To allow arm64 syscalls accept tagged pointers from userspace, we must
untag them when they are passed to the kernel. Since untagging is done in
generic parts of the kernel, the untagged_addr macro needs to be defined
for all architectures.
Define it as a noop for other architectures besides
The utilization is a well defined property of tasks and CPUs with an
in-kernel representation based on power-of-two values.
The current representation, in the [0..SCHED_CAPACITY_SCALE] range,
allows efficient computations in hot-paths and a sufficient fixed point
arithmetic precision.
However, the
strncpy_from_user and strnlen_user accept user addresses as arguments, and
do not go through the same path as copy_from_user and others, so here we
need to handle the case of tagged user addresses separately.
Untag user pointers passed to these functions.
Signed-off-by: Andrey Konovalov
---
Utilization clamp values enforced on a CPU by a task can be updated at
run-time, for example via a sched_setattr syscall, while a task is
currently RUNNABLE on that CPU. In these cases, the task can be already
refcounting a clamp group for its CPU and thus we need to update this
reference to
To allow arm64 syscalls accept tagged pointers from userspace, we must
untag them when they are passed to the kernel. Since untagging is done in
generic parts of the kernel, the untagged_addr macro needs to be defined
for all architectures.
Define it as a noop for other architectures besides
The utilization is a well defined property of tasks and CPUs with an
in-kernel representation based on power-of-two values.
The current representation, in the [0..SCHED_CAPACITY_SCALE] range,
allows efficient computations in hot-paths and a sufficient fixed point
arithmetic precision.
However, the
strncpy_from_user and strnlen_user accept user addresses as arguments, and
do not go through the same path as copy_from_user and others, so here we
need to handle the case of tagged user addresses separately.
Untag user pointers passed to these functions.
Signed-off-by: Andrey Konovalov
---
Currently schedutil enforces a maximum frequency when RT tasks are
RUNNABLE. Such a mandatory policy can be made more tunable from
userspace thus allowing for example to define a max frequency which is
still reasonable for the execution of a specific RT workload. This
will contribute to make the
Utilization clamping allows to clamp the utilization of a CPU within a
[util_min, util_max] range. This range depends on the set of currently
RUNNABLE tasks on a CPU, where each task references two "clamp groups"
defining the util_min and the util_max clamp values to be considered for
that task.
This is a respin of:
https://lore.kernel.org/lkml/20180716082906.6061-1-patrick.bell...@arm.com
Which has been rebased on today's tip/sched/core:
commit 1b6266ebe3da ("watchdog: Reduce message verbosity")
and addresses all the comments from Tejun and Suren, thanks for your feedback!
When a task's util_clamp value is configured via sched_setattr(2), this
value has to be properly accounted in the corresponding clamp group
every time the task is enqueued and dequeued. When cgroups are also in
use, per-task clamp values have to be aggregated to those of the CPU's
controller's
Each time a frequency update is required via schedutil, a frequency is
selected to (possibly) satisfy the utilization reported by the CFS
class. However, when utilization clamping is in use, the frequency
selection should consider the requirements suggested by userspace, for
example, to:
- boost
This patch adds a simple test, that calls the uname syscall with a
tagged user pointer as an argument. Without the kernel accepting tagged
user pointers the test fails with EFAULT.
Signed-off-by: Andrey Konovalov
---
tools/testing/selftests/arm64/.gitignore | 1 +
401 - 500 of 1270 matches
Mail list logo
