On Mon, Apr 19, 2021 at 2:01 AM Peter Zijlstra wrote:
>
> Josh, you being on the other Google team, the one that actually uses the
> cgroup interface AFAIU, can you fight the good fight with TJ on this?
A bit of extra context is in
Hi Peter,
Looks reasonable to me.
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -4756,7 +4756,8 @@
>
> sbni= [NET] Granch SBNI12 leased line adapter
>
> - sched_debug [KNL] Enables verbose
On Fri, Apr 16, 2021 at 8:05 AM Peter Zijlstra wrote:
>
> On Tue, Mar 30, 2021 at 03:44:12PM -0700, Josh Don wrote:
> > Peter,
> >
> > Since you've already pulled the need_resched warning patch into your
> > tree, I'm including just the diff based on that patch (in
if the tick is disabled.
This feature (LATENCY_WARN) is default disabled.
Signed-off-by: Paul Turner
Signed-off-by: Josh Don
Signed-off-by: Peter Zijlstra (Intel)
Link: https://lkml.kernel.org/r/20210323035706.572953-1-josh...@google.com
---
This squashes the fixup from https://lkml.org/lkml/2021/3
On Thu, Apr 8, 2021 at 9:47 AM Peter Zijlstra wrote:
>
> On Thu, Apr 08, 2021 at 03:25:52PM +0200, Michal Koutný wrote:
>
> > I'm curious whether the cgroup API actually simplifies things that are
> > possible with the clone/prctl API or allows anything that wouldn't be
> > otherwise possible.
>
Hi Peter,
I walked through the reference counting, and it seems good to me
(though it did take a few passes to fully digest the invariants for
the fat cookie stuff).
> +unsigned long sched_core_alloc_cookie(unsigned int type)
> {
> struct sched_core_cookie *ck = kmalloc(sizeof(*ck),
Thanks, allowing for multiple group cookies in a hierarchy is a nice
improvement.
> + if (tgi != tg) {
> + if (tgi->core_cookie || (tgi->core_parent &&
> tgi->core_parent != tg))
> + continue;
> +
> +
> +/*
> + * sched_core_update_cookie - Common helper to update a task's core cookie.
> This
> + * updates the selected cookie field.
> + * @p: The task whose cookie should be updated.
> + * @cookie: The new cookie.
> + * @cookie_type: The cookie field to which the cookie corresponds.
No
00:00:00 2001
From: Josh Don
Date: Mon, 22 Mar 2021 20:57:06 -0700
Subject: [PATCH] fixup: sched: Warn on long periods of pending need_resched
---
kernel/sched/core.c | 29 -
1 file changed, 12 insertions(+), 17 deletions(-)
diff --git a/kernel/sched/core.c b/ker
On Mon, Mar 29, 2021 at 2:55 AM Peter Zijlstra wrote:
>
> OK, fixed the fails. My tired head made it unconditionally return the
> cookie-id of 'current' instead of task. Pushed out an update.
I see you have the per-task and prctl stuff pulled into your tree. I
can rebase the compound cookie and
On Tue, Mar 30, 2021 at 2:29 AM Peter Zijlstra wrote:
> > On Wed, Mar 24, 2021 at 05:40:17PM -0400, Joel Fernandes (Google) wrote:
> > > +
> > > + if (!tg->core_tagged && val) {
> > > + /* Tag is being set. Check ancestors and descendants. */
> > > + if
Hi Peter,
On Fri, Mar 26, 2021 at 5:10 PM Peter Zijlstra wrote:
>
> On Wed, Mar 24, 2021 at 05:40:14PM -0400, Joel Fernandes (Google) wrote:
> > From: Josh Don
> >
> > A single unsigned long is insufficient as a cookie value for core
> > scheduling. We wil
> On Wed, Mar 24, 2021 at 01:39:16PM +, Mel Gorman wrote:
> I'm not going to NAK because I do not have hard data that shows they must
> exist. However, I won't ACK either because I bet a lot of tasty beverages
> the next time we meet that the following parameters will generate reports
> if
On Wed, Mar 24, 2021 at 4:27 AM Mel Gorman wrote:
>
> I'm not a fan of the name. I know other sysctls have _enabled in the
> name but it's redundant. If you say the name out loud, it sounds weird.
> I would suggest an alternative but see below.
Now using the version rebased by Peter; this
On Mon, Mar 22, 2021 at 8:54 PM Li, Aubrey wrote:
>
> On 2021/3/22 20:56, Peter Zijlstra wrote:
> > On Mon, Mar 22, 2021 at 08:31:09PM +0800, Li, Aubrey wrote:
> >> Please let me know if I put cookie match check at the right position
> >> in task_hot(), if so, I'll obtain some performance data of
if the tick is disabled.
This feature is default disabled. It can be toggled on using sysctl
resched_latency_warn_enabled.
Signed-off-by: Paul Turner
Signed-off-by: Josh Don
---
Delta from v1:
- separate sysctl for enabling/disabling and triggering warn_once
behavior
- add documentation
- static
On Fri, Mar 19, 2021 at 2:02 AM Mel Gorman wrote:
>
> Default disabling and hidden behind a static branch would be useful
> because the majority of users are not going to know what to do about
> a need_resched warning and the sysctl is not documented. As Ingo said,
> SCHED_DEBUG is enabled by
> > +static unsigned long sched_core_alloc_task_cookie(void)
> > +{
> > + struct sched_core_task_cookie *ck =
> > + kmalloc(sizeof(struct sched_core_task_cookie), GFP_KERNEL);
>
> struct sched_core_task_cookie *ck = kmalloc(sizeof(*ck), GFP_KERNEL);
>
> Also, those type
The warning is WAI (holding spinlock for 100ms). However, since this
is expected for locktorture, it makes sense to not have the warning
enabled while the test is running. I can add that to the patch.
On Wed, Mar 17, 2021 at 1:31 AM Ingo Molnar wrote:
>
>
> * Josh Don wrote:
>
> > +static inline u64 resched_latency_check(struct rq *rq)
> > +{
> > + int latency_warn_ms = READ_ONCE(sysctl_resched_latency_warn_ms);
> > + bo
On Wed, Mar 17, 2021 at 1:25 AM Ingo Molnar wrote:
>
> * Josh Don wrote:
>
> > If resched_latency_warn_ms is set to the default value, only one warning
> > will be produced per boot.
>
> Looks like a value hack, should probably be a separate flag,
> defaulti
, only one warning
will be produced per boot.
This warning only exists under CONFIG_SCHED_DEBUG. If it goes off, it is
likely that there is a missing cond_resched() somewhere.
Signed-off-by: Paul Turner
Signed-off-by: Josh Don
---
We've caught various bugs using this patch. In fact, a followup
On Thu, Mar 4, 2021 at 9:34 AM Nick Desaulniers wrote:
>
>
> Hi Josh, Thanks for helping get this patch across the finish line.
> Would you mind updating the commit message to point to
> https://bugs.llvm.org/show_bug.cgi?id=20197?
Sure thing, just saw that it got marked as a dup.
Peter, since
On Wed, Mar 3, 2021 at 2:02 AM Peter Zijlstra wrote:
>
> On Tue, Mar 02, 2021 at 12:57:37PM -0800, Josh Don wrote:
> > On gcc, the asm versions of `fls` are about the same speed as the
> > builtin. On clang, the versions that use fls (fls,fls64) are more than
> > twic
n> 1.32ms ±11%
```
Signed-off-by: Clement Courbet
Signed-off-by: Josh Don
---
kernel/sched/fair.c | 19 +++
kernel/sched/sched.h | 1 +
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 8a8bd7b13634..a69137196
> you made fact_hi u32, why can't we unconditionally use fls() ?
Thanks for clarifying with ILP32; will remove this macro and simplify
to just fls().
s ±11%
```
Signed-off-by: Clement Courbet
Signed-off-by: Josh Don
---
kernel/sched/fair.c | 30 ++
kernel/sched/sched.h | 1 +
2 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 8a8bd7b13634..67e5a1d53
On Fri, Feb 26, 2021 at 1:03 PM Peter Zijlstra wrote:
>
> On Fri, Feb 26, 2021 at 11:52:39AM -0800, Josh Don wrote:
> > From: Clement Courbet
> >
> > A significant portion of __calc_delta time is spent in the loop
> > shifting a u64 by 32 bits. Use a __bu
On Fri, Feb 26, 2021 at 12:08 PM Chris Hyser wrote:
>
> Update:
>
> The clone syscall stress test I have is causing a deadlock with this patchset
> when
> compiled with CONFIG_PROVE_RAW_LOCK_NESTING=y. I am able to get stacktraces
> with
> nmi_watchdog and am looking through those. Josh was not
From: Clement Courbet
A significant portion of __calc_delta time is spent in the loop
shifting a u64 by 32 bits. Use a __builtin_clz instead of iterating.
This is ~7x faster on benchmarks.
Signed-off-by: Clement Courbet
Signed-off-by: Josh Don
---
kernel/sched/fair.c | 30
On Tue, Feb 23, 2021 at 11:26 AM Chris Hyser wrote:
>
> On 2/23/21 4:05 AM, Peter Zijlstra wrote:
> > On Mon, Feb 22, 2021 at 11:00:37PM -0500, Chris Hyser wrote:
> >> On 1/22/21 8:17 PM, Joel Fernandes (Google) wrote:
> >> While trying to test the new prctl() code I'm working on, I ran into a
On Fri, Feb 5, 2021 at 3:53 AM Peter Zijlstra wrote:
>
> On Fri, Jan 22, 2021 at 08:17:01PM -0500, Joel Fernandes (Google) wrote:
>
> > +/* All active sched_core_cookies */
> > +static struct rb_root sched_core_cookies = RB_ROOT;
> > +static DEFINE_RAW_SPINLOCK(sched_core_cookies_lock);
>
> > +/*
On Thu, Feb 4, 2021 at 6:36 AM Peter Zijlstra wrote:
>
> refcount_dec_and_lock() avoids that complication.
There isn't currently an interface for raw_spin_locks. Certainly could
add a new interface in a separate patch as part of this series, but
doesn't seem that bad to do the locking inline.
On Thu, Feb 4, 2021 at 6:02 AM Peter Zijlstra wrote:
>
> On Fri, Jan 22, 2021 at 08:17:01PM -0500, Joel Fernandes (Google) wrote:
>
> > +#ifdef CONFIG_SCHED_DEBUG
> > + /* Read the group cookie. */
> > + {
> > + .name = "core_group_cookie",
> > + .flags =
On Thu, Feb 4, 2021 at 5:54 AM Peter Zijlstra wrote:
>
> On Fri, Jan 22, 2021 at 08:17:01PM -0500, Joel Fernandes (Google) wrote:
> > From: Peter Zijlstra
>
> I'm thinking this is too much credit, I didn't write much of this.
>
> > Marks all tasks in a cgroup as matching for core-scheduling.
> >
On Wed, Dec 2, 2020 at 12:02 AM Peter Zijlstra wrote:
>
> On Tue, Dec 01, 2020 at 10:18:00PM -0800, Josh Don wrote:
> > Hey Peter,
> >
> > On Wed, Nov 25, 2020 at 5:43 AM Peter Zijlstra wrote:
> > >
> > > Why can't the above work by setting 'ta
On Tue, Dec 1, 2020 at 11:55 PM Peter Zijlstra wrote:
>
> Then disallow sharing a task cookie when the tasks are in different
> cgroups or disallow cgroup movement when they share a cookie.
Yes, we could restrict task cookie sharing to tasks that are in the
same cgroup. Then the cookie easily
On Tue, Dec 1, 2020 at 11:35 AM Peter Zijlstra wrote:
>
> So I don't think that later patch is right... That is, it works, but
> afaict it's massive overkill.
>
> COOKIE_CMP_RETURN(task_cookie);
> COOKIE_CMP_RETURN(group_cookie);
> COOKIE_CMP_RETURN(color);
>
> So if
Hey Peter,
On Wed, Nov 25, 2020 at 5:43 AM Peter Zijlstra wrote:
>
> Why can't the above work by setting 'tag' (that's a terrible name, why
> does that still live) in CDE? Have the most specific tag live. Same with
> that thread stuff.
The motivation is to allow an unprivileged user the ability
On Mon, Oct 19, 2020 at 6:45 PM Joel Fernandes (Google)
wrote:
>
> +static unsigned long cpu_core_get_group_cookie(struct task_group *tg)
> +{
> + unsigned long color = 0;
> +
> + if (!tg)
> + return 0;
> +
> + for (; tg; tg = tg->parent) {
> + if
On Fri, Oct 23, 2020 at 10:49 AM Jakub Kicinski wrote:
>
> On Thu, 22 Oct 2020 20:29:42 -0700 Josh Don wrote:
> > Busy polling loops in the kernel such as network socket poll and kvm
> > halt polling have performance problems related to process scheduler load
> >
On Fri, Oct 23, 2020 at 12:19 AM Peter Zijlstra wrote:
>
> On Thu, Oct 22, 2020 at 08:29:42PM -0700, Josh Don wrote:
> > Busy polling loops in the kernel such as network socket poll and kvm
> > halt polling have performance problems related to process scheduler load
> >
Add the new functions prepare_to_busy_poll() and friends to
napi_busy_loop(). The busy polling cpu will be considered an idle
target during wake up balancing.
Suggested-by: Xi Wang
Signed-off-by: Josh Don
Signed-off-by: Xi Wang
---
net/core/dev.c | 8
1 file changed, 4 insertions
Wang
Signed-off-by: Josh Don
Signed-off-by: Xi Wang
---
virt/kvm/kvm_main.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index cf88233b819a..8f818f0fc979 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2772,7
to find an idle cpu
via wakeup cpu selection.
Suggested-by: Xi Wang
Signed-off-by: Josh Don
Signed-off-by: Xi Wang
---
include/linux/sched.h | 5 +++
kernel/sched/core.c | 94 +++
kernel/sched/fair.c | 25
kernel/sched/sched.h | 2 +
4 files
The following commit has been merged into the sched/core branch of tip:
Commit-ID: ec73240b1627cddfd7cef018c7fa1c32e64a721e
Gitweb:
https://git.kernel.org/tip/ec73240b1627cddfd7cef018c7fa1c32e64a721e
Author:Josh Don
AuthorDate:Tue, 04 Aug 2020 12:34:13 -07:00
Committer
SMT siblings share caches, so cache hotness should be irrelevant for
cross-sibling migration.
Proposed-by: Venkatesh Pallipadi
Signed-off-by: Josh Don
---
kernel/sched/fair.c | 4
1 file changed, 4 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 1a68a0536add
On Tue, Aug 4, 2020 at 3:56 AM wrote:
>
> On Mon, Aug 03, 2020 at 05:06:14PM -0700, Josh Don wrote:
> > SMT siblings share caches, so cache hotness should be irrelevant for
> > cross-sibling migration.
> >
> > Proposed-by: Venkatesh Pallipadi
> > Signed-o
SMT siblings share caches, so cache hotness should be irrelevant for
cross-sibling migration.
Proposed-by: Venkatesh Pallipadi
Signed-off-by: Josh Don
---
kernel/sched/fair.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 2ba8f230feb9
Hey Andy, thanks for taking a look.
On Fri, Jul 17, 2020 at 8:14 PM Andy Lutomirski wrote:
>
> PeterZ and I fixed a whole series of bugs a few years ago, and remote
> wakeups *should* already do this. Did we miss something? Did it
> regress? Even the call_function_single path ought to go
h violates the assumption that
softirq can only be run either on the tail of a hard IRQ or inline on
a non-idle thread via local_bh_enable(), since we can now process
softirq inline within the idle loop. These ssues can be resolved in a
later version of this patch.
Signed-off-by: Josh Don
---
gs);
> - raw_spin_unlock_irqrestore(_b->lock, flags);
> }
Thanks, I missed the now-useless lock acquire in my revert.
s/elimite/eliminate
Reviewed-by: Josh Don
Best,
Josh
The following commit has been merged into the sched/core branch of tip:
Commit-ID: ab93a4bc955b3980c699430bc0b633f0d8b607be
Gitweb:
https://git.kernel.org/tip/ab93a4bc955b3980c699430bc0b633f0d8b607be
Author:Josh Don
AuthorDate:Fri, 10 Apr 2020 15:52:08 -07:00
Committer
53 matches
Mail list logo
