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 | 4
1 file changed, 4 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 1a68a0536add
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
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
> >
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
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
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
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 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 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
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 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
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
> >
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
---
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
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
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 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 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
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
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
> +/*
> + * 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
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;
> +
> +
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),
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
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 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
, 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
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: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
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
> 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().
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
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
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
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 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 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
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 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,
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 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
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 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);
>
> > +/*
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
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