Re: [PATCH v3] sched/fair: fix unthrottle_cfs_rq for leaf_cfs_rq list

Vincent Guittot writes: > Although not exactly identical, unthrottle_cfs_rq() and enqueue_task_fair() > are quite close and follow the same sequence for enqueuing an entity in the > cfs hierarchy. Modify unthrottle_cfs_rq() to use the same pattern as > enqueue_task_fair(). This fixes a problem

Re: [PATCH] sched/fair: fix unthrottle_cfs_rq for leaf_cfs_rq list

Vincent Guittot writes: > On Tue, 12 May 2020 at 20:59, wrote: >> >> Vincent Guittot writes: >> >> > Although not exactly identical, unthrottle_cfs_rq() and enqueue_task_fair() >> > are quite close and follow the same sequence for enqueuing an entity in the >> > cfs hierarchy. Modify

Re: [PATCH] sched/fair: fix unthrottle_cfs_rq for leaf_cfs_rq list

Vincent Guittot writes: > Although not exactly identical, unthrottle_cfs_rq() and enqueue_task_fair() > are quite close and follow the same sequence for enqueuing an entity in the > cfs hierarchy. Modify unthrottle_cfs_rq() to use the same pattern as > enqueue_task_fair(). This fixes a problem

Re: [PATCH] sched/fair: don't assign runtime for throttled cfs_rq

Valentin Schneider writes: > On 23/08/2019 21:00, bseg...@google.com wrote: > [...] >> Could you mention in the message that this a throttled cfs_rq can have >> account_cfs_rq_runtime called on it because it is throttled before >> idle_balance, and the idle_balance calls update_rq_clock to add

Re: [PATCH] sched/fair: don't assign runtime for throttled cfs_rq

Liangyan writes: > do_sched_cfs_period_timer() will refill cfs_b runtime and call > distribute_cfs_runtime() to unthrottle cfs_rq, sometimes cfs_b->runtime > will allocate all quota to one cfs_rq incorrectly. > This will cause other cfs_rq can't get runtime and will be throttled. > We find that

Re: [PATCH -next v2] sched/fair: fix -Wunused-but-set-variable warnings

Dave Chiluk writes: > On Wed, Aug 21, 2019 at 12:36 PM wrote: >> >> Qian Cai writes: >> >> > The linux-next commit "sched/fair: Fix low cpu usage with high >> > throttling by removing expiration of cpu-local slices" [1] introduced a >> > few compilation warnings, >> > >> > kernel/sched/fair.c:

Re: [PATCH] sched/fair: Add missing unthrottle_cfs_rq()

Valentin Schneider writes: > Turns out a cfs_rq->runtime_remaining can become positive in > assign_cfs_rq_runtime(), but this codepath has no call to > unthrottle_cfs_rq(). > > This can leave us in a situation where we have a throttled cfs_rq with > positive ->runtime_remaining, which breaks the

Re: [PATCH] sched/fair: Add missing unthrottle_cfs_rq()

Peter Zijlstra writes: > On Tue, Aug 20, 2019 at 11:54:20AM +0100, Valentin Schneider wrote: >> Turns out a cfs_rq->runtime_remaining can become positive in >> assign_cfs_rq_runtime(), but this codepath has no call to >> unthrottle_cfs_rq(). >> >> This can leave us in a situation where we have

Re: [PATCH -next v2] sched/fair: fix -Wunused-but-set-variable warnings

Qian Cai writes: > The linux-next commit "sched/fair: Fix low cpu usage with high > throttling by removing expiration of cpu-local slices" [1] introduced a > few compilation warnings, > > kernel/sched/fair.c: In function '__refill_cfs_bandwidth_runtime': > kernel/sched/fair.c:4365:6: warning:

Re: [PATCH -next] sched/fair: fix -Wunused-but-set-variable warnings

Qian Cai writes: > The linux-next commit "sched/fair: Fix low cpu usage with high > throttling by removing expiration of cpu-local slices" [1] introduced a > few compilation warnings, > > kernel/sched/fair.c: In function '__refill_cfs_bandwidth_runtime': > kernel/sched/fair.c:4365:6: warning:

Re: [PATCH v4 1/1] sched/fair: Return all runtime when cfs_b has very little remaining.

Dave Chiluk writes: > On Mon, Jun 24, 2019 at 10:33:07AM -0700, bseg...@google.com wrote: >> This still has a similar cost as reducing min_cfs_rq_runtime to 0 - we >> now take a tg-global lock on every group se dequeue. Setting min=0 means >> that we have to take it on both enqueue and dequeue,

Re: [PATCH v4 1/1] sched/fair: Return all runtime when cfs_b has very little remaining.

Dave Chiluk writes: > It has been observed, that highly-threaded, user-interactive > applications running under cpu.cfs_quota_us constraints can hit a high > percentage of periods throttled while simultaneously not consuming the > allocated amount of quota. This impacts user-interactive non-cpu

Re: [PATCH v2] sched/fair: don't push cfs_bandwith slack timers forward

Peter Zijlstra writes: > On Thu, Jun 06, 2019 at 10:21:01AM -0700, bseg...@google.com wrote: >> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h >> index efa686eeff26..60219acda94b 100644 >> --- a/kernel/sched/sched.h >> +++ b/kernel/sched/sched.h >> @@ -356,6 +356,7 @@ struct

[PATCH v2] sched/fair: don't push cfs_bandwith slack timers forward

When a cfs_rq sleeps and returns its quota, we delay for 5ms before waking any throttled cfs_rqs to coalesce with other cfs_rqs going to sleep, as this has to be done outside of the rq lock we hold. The current code waits for 5ms without any sleeps, instead of waiting for 5ms from the first

Re: [PATCH] sched/fair: don't restart enqueued cfs quota slack timer

y >> and may have no chance to expire to unthrottle cfs tasks. >> This will cause that the throttled tasks can't be unthrottled in time >> although they have remaining quota. > > This looks very similar to the patch from Ben here: > > https://lkml.kernel.org/r/xm26blzlyr9d

Re: [PATCH v3 1/1] sched/fair: Fix low cpu usage with high throttling by removing expiration of cpu-local slices

Dave Chiluk writes: > On Wed, May 29, 2019 at 02:05:55PM -0700, bseg...@google.com wrote: >> Dave Chiluk writes: >> >> Yeah, having run the test, stranding only 1 ms per cpu rather than 5 >> doesn't help if you only have 10 ms of quota and even 10 threads/cpus. >> The slack timer isn't

Re: [PATCH] sched/fair: Limit sched_cfs_period_timer loop to avoid hard lockup

Phil Auld writes: > On Fri, Mar 15, 2019 at 05:03:47PM +0100 Peter Zijlstra wrote: >> On Fri, Mar 15, 2019 at 11:30:42AM -0400, Phil Auld wrote: >> >> >> I'll rework the maths in the averaged version and post v2 if that makes >> >> sense. >> > >> > It may have the extra timer fetch, although

Re: [RFC] sched/fair: hard lockup in sched_cfs_period_timer

Phil Auld writes: > On Wed, Mar 13, 2019 at 10:44:09AM -0700 bseg...@google.com wrote: >> Phil Auld writes: >> >> > On Mon, Mar 11, 2019 at 04:25:36PM -0400 Phil Auld wrote: >> >> On Mon, Mar 11, 2019 at 10:44:25AM -0700 bseg...@google.com wrote: >> >> > Letting it spin for 100ms and then only

Re: [RFC] sched/fair: hard lockup in sched_cfs_period_timer

Phil Auld writes: > On Mon, Mar 11, 2019 at 04:25:36PM -0400 Phil Auld wrote: >> On Mon, Mar 11, 2019 at 10:44:25AM -0700 bseg...@google.com wrote: >> > Letting it spin for 100ms and then only increasing by 6% seems extremely >> > generous. If we went this route I'd probably say "after looping N

Re: [RFC] sched/fair: hard lockup in sched_cfs_period_timer

Phil Auld writes: > On Mon, Mar 11, 2019 at 10:44:25AM -0700 bseg...@google.com wrote: >> Phil Auld writes: >> >> > On Wed, Mar 06, 2019 at 11:25:02AM -0800 bseg...@google.com wrote: >> >> Phil Auld writes: >> >> >> >> > On Tue, Mar 05, 2019 at 12:45:34PM -0800 bseg...@google.com wrote: >>

Re: [RFC] sched/fair: hard lockup in sched_cfs_period_timer

Phil Auld writes: > On Wed, Mar 06, 2019 at 11:25:02AM -0800 bseg...@google.com wrote: >> Phil Auld writes: >> >> > On Tue, Mar 05, 2019 at 12:45:34PM -0800 bseg...@google.com wrote: >> >> Phil Auld writes: >> >> >> >> > Interestingly, if I limit the number of child cgroups to the number of

Re: [RFC] sched/fair: hard lockup in sched_cfs_period_timer

Phil Auld writes: > On Tue, Mar 05, 2019 at 12:45:34PM -0800 bseg...@google.com wrote: >> Phil Auld writes: >> >> > Interestingly, if I limit the number of child cgroups to the number of >> > them I'm actually putting processes into (16 down from 2500) the problem >> > does not reproduce. >>

Re: [RFC] sched/fair: hard lockup in sched_cfs_period_timer

Phil Auld writes: > On Tue, Mar 05, 2019 at 10:49:01AM -0800 bseg...@google.com wrote: >> Phil Auld writes: >> >> >> > >> >> > raw_spin_lock(_b->lock); >> >> > for (;;) { >> >> > overrun = hrtimer_forward_now(timer, cfs_b->period); >> >> > if

Re: [RFC] sched/fair: hard lockup in sched_cfs_period_timer

Phil Auld writes: >> > >> >raw_spin_lock(_b->lock); >> >for (;;) { >> >overrun = hrtimer_forward_now(timer, cfs_b->period); >> >if (!overrun) >> >break; >> > >> >idle = do_sched_cfs_period_timer(cfs_b, overrun); >> >} >> >if

Re: [RFC] sched/fair: hard lockup in sched_cfs_period_timer

Phil Auld writes: > Hi, > > I have a reproducible case of this: > > [ 217.264946] NMI watchdog: Watchdog detected hard LOCKUP on cpu 24 > [ 217.264948] Modules linked in: sunrpc iTCO_wdt gpio_ich > iTCO_vendor_support intel_powerclamp coretemp kvm_intel kvm ipmi_ssif > irqbypass

Re: [Patch] sched/fair: Avoid throttle_list starvation with low cfs quota

Ingo Molnar writes: > I've Cc:-ed a handful of gents who worked on CFS bandwidth details to widen > the discussion. > Patch quoted below. > > Looks like a real bug that needs to be fixed - and at first sight the quota > of 1000 looks very > low - could we improve the arithmetics perhaps? > >

Re: [Patch] sched/fair: Avoid throttle_list starvation with low cfs quota

Ingo Molnar writes: > I've Cc:-ed a handful of gents who worked on CFS bandwidth details to widen > the discussion. > Patch quoted below. > > Looks like a real bug that needs to be fixed - and at first sight the quota > of 1000 looks very > low - could we improve the arithmetics perhaps? > >

Re: [PATCH] sched/fair: sync expires_seq in distribute_cfs_runtime()

Cong Wang writes: > On Tue, Jul 31, 2018 at 10:13 AM wrote: >> >> Xunlei Pang writes: >> >> > On 7/31/18 1:55 AM, Cong Wang wrote: >> >> On Sun, Jul 29, 2018 at 10:29 PM Xunlei Pang >> >> wrote: >> >>> >> >>> Hi Cong, >> >>> >> >>> On 7/28/18 8:24 AM, Cong Wang wrote: >> Each time we

Re: [PATCH] sched/fair: sync expires_seq in distribute_cfs_runtime()

Cong Wang writes: > On Tue, Jul 31, 2018 at 10:13 AM wrote: >> >> Xunlei Pang writes: >> >> > On 7/31/18 1:55 AM, Cong Wang wrote: >> >> On Sun, Jul 29, 2018 at 10:29 PM Xunlei Pang >> >> wrote: >> >>> >> >>> Hi Cong, >> >>> >> >>> On 7/28/18 8:24 AM, Cong Wang wrote: >> Each time we

Re: [PATCH] sched/fair: sync expires_seq in distribute_cfs_runtime()

Xunlei Pang writes: > On 7/31/18 1:55 AM, Cong Wang wrote: >> On Sun, Jul 29, 2018 at 10:29 PM Xunlei Pang >> wrote: >>> >>> Hi Cong, >>> >>> On 7/28/18 8:24 AM, Cong Wang wrote: Each time we sync cfs_rq->runtime_expires with cfs_b->runtime_expires, we should sync its ->expires_seq

Re: [PATCH] sched/fair: sync expires_seq in distribute_cfs_runtime()

Xunlei Pang writes: > On 7/31/18 1:55 AM, Cong Wang wrote: >> On Sun, Jul 29, 2018 at 10:29 PM Xunlei Pang >> wrote: >>> >>> Hi Cong, >>> >>> On 7/28/18 8:24 AM, Cong Wang wrote: Each time we sync cfs_rq->runtime_expires with cfs_b->runtime_expires, we should sync its ->expires_seq

Re: [PATCH] sched/fair: sync expires_seq in distribute_cfs_runtime()

Xunlei Pang writes: > Hi Cong, > > On 7/28/18 8:24 AM, Cong Wang wrote: >> Each time we sync cfs_rq->runtime_expires with cfs_b->runtime_expires, >> we should sync its ->expires_seq too. However it is missing >> for distribute_cfs_runtime(), especially the slack timer call path. > > I don't

Re: [PATCH] sched/fair: sync expires_seq in distribute_cfs_runtime()

Xunlei Pang writes: > Hi Cong, > > On 7/28/18 8:24 AM, Cong Wang wrote: >> Each time we sync cfs_rq->runtime_expires with cfs_b->runtime_expires, >> we should sync its ->expires_seq too. However it is missing >> for distribute_cfs_runtime(), especially the slack timer call path. > > I don't

Re: [PATCH v2 2/2] sched/fair: Advance global expiration when period timer is restarted

Xunlei Pang writes: > When period gets restarted after some idle time, start_cfs_bandwidth() > doesn't update the expiration information, expire_cfs_rq_runtime() will > see cfs_rq->runtime_expires smaller than rq clock and go to the clock > drift logic, wasting needless cpu cycles on the

Re: [PATCH v2 2/2] sched/fair: Advance global expiration when period timer is restarted

Xunlei Pang writes: > When period gets restarted after some idle time, start_cfs_bandwidth() > doesn't update the expiration information, expire_cfs_rq_runtime() will > see cfs_rq->runtime_expires smaller than rq clock and go to the clock > drift logic, wasting needless cpu cycles on the

Re: [PATCH v2 1/2] sched/fair: Fix bandwidth timer clock drift condition

Xunlei Pang writes: > I noticed the group constantly got throttled even it consumed > low cpu usage, this caused some jitters on the response time > to some of our business containers enabling cpu quota. > > It's very simple to reproduce: > mkdir /sys/fs/cgroup/cpu/test > cd

Re: [PATCH v2 1/2] sched/fair: Fix bandwidth timer clock drift condition

Xunlei Pang writes: > I noticed the group constantly got throttled even it consumed > low cpu usage, this caused some jitters on the response time > to some of our business containers enabling cpu quota. > > It's very simple to reproduce: > mkdir /sys/fs/cgroup/cpu/test > cd

Re: [PATCH 2/2] sched/fair: Advance global expiration when period timer is restarted

Xunlei Pang writes: > On 6/19/18 2:58 AM, bseg...@google.com wrote: >> Xunlei Pang writes: >> >>> I noticed the group frequently got throttled even it consumed >>> low cpu usage, this caused some jitters on the response time >>> to some of our business containers enabling cpu quota. >>> >>>

Re: [PATCH 2/2] sched/fair: Advance global expiration when period timer is restarted

Xunlei Pang writes: > On 6/19/18 2:58 AM, bseg...@google.com wrote: >> Xunlei Pang writes: >> >>> I noticed the group frequently got throttled even it consumed >>> low cpu usage, this caused some jitters on the response time >>> to some of our business containers enabling cpu quota. >>> >>>

Re: [PATCH 2/2] sched/fair: Advance global expiration when period timer is restarted

Xunlei Pang writes: > I noticed the group frequently got throttled even it consumed > low cpu usage, this caused some jitters on the response time > to some of our business containers enabling cpu quota. > > It's very easy to reproduce: > mkdir /sys/fs/cgroup/cpu/test > cd

Re: [PATCH 2/2] sched/fair: Advance global expiration when period timer is restarted

Xunlei Pang writes: > I noticed the group frequently got throttled even it consumed > low cpu usage, this caused some jitters on the response time > to some of our business containers enabling cpu quota. > > It's very easy to reproduce: > mkdir /sys/fs/cgroup/cpu/test > cd

Re: [PATCH 1/2] sched/fair: Fix bandwidth timer clock drift condition

Xunlei Pang writes: > The current condition to judge clock drift in expire_cfs_rq_runtime() > is wrong, the two runtime_expires are actually the same when clock > drift happens, so this condtion can never hit. The orginal design was > correctly done by commit a9cf55b28610 ("sched: Expire invalid

Re: [PATCH 1/2] sched/fair: Fix bandwidth timer clock drift condition

Xunlei Pang writes: > The current condition to judge clock drift in expire_cfs_rq_runtime() > is wrong, the two runtime_expires are actually the same when clock > drift happens, so this condtion can never hit. The orginal design was > correctly done by commit a9cf55b28610 ("sched: Expire invalid

[PATCHv2] ptrace: fix PTRACE_LISTEN race corrupting task->state

In PT_SEIZED + LISTEN mode STOP/CONT signals cause a wakeup against __TASK_TRACED. If this races with the ptrace_unfreeze_traced at the end of a PTRACE_LISTEN, this can wake the task /after/ the check against __TASK_TRACED, but before the reset of state to TASK_TRACED. This causes it to instead

[PATCHv2] ptrace: fix PTRACE_LISTEN race corrupting task->state

In PT_SEIZED + LISTEN mode STOP/CONT signals cause a wakeup against __TASK_TRACED. If this races with the ptrace_unfreeze_traced at the end of a PTRACE_LISTEN, this can wake the task /after/ the check against __TASK_TRACED, but before the reset of state to TASK_TRACED. This causes it to instead

Re: [PATCH] ptrace: fix PTRACE_LISTEN race corrupting task->state

Oleg Nesterov writes: > (add akpm, we usually route ptrace fixes via -mm tree) > > On 02/21, bseg...@google.com wrote: >> >> --- a/kernel/ptrace.c >> +++ b/kernel/ptrace.c >> @@ -184,10 +184,14 @@ static void ptrace_unfreeze_traced(struct task_struct >> *task) >> >>

Re: [PATCH] ptrace: fix PTRACE_LISTEN race corrupting task->state

Oleg Nesterov writes: > (add akpm, we usually route ptrace fixes via -mm tree) > > On 02/21, bseg...@google.com wrote: >> >> --- a/kernel/ptrace.c >> +++ b/kernel/ptrace.c >> @@ -184,10 +184,14 @@ static void ptrace_unfreeze_traced(struct task_struct >> *task) >> >>

Re: [PATCH] ptrace: fix PTRACE_LISTEN race corrupting task->state

Oleg Nesterov writes: > On 02/21, bseg...@google.com wrote: >> >> In PT_SEIZED + LISTEN mode SIGSTOP/SIGCONT signals cause a wakeup >> against __TASK_TRACED. If this races with the ptrace_unfreeze_traced at >> the end of a PTRACE_LISTEN, this can wake the task /after/ the check

Re: [PATCH] ptrace: fix PTRACE_LISTEN race corrupting task->state

Oleg Nesterov writes: > On 02/21, bseg...@google.com wrote: >> >> In PT_SEIZED + LISTEN mode SIGSTOP/SIGCONT signals cause a wakeup >> against __TASK_TRACED. If this races with the ptrace_unfreeze_traced at >> the end of a PTRACE_LISTEN, this can wake the task /after/ the check >> against

[PATCH] ptrace: fix PTRACE_LISTEN race corrupting task->state

In PT_SEIZED + LISTEN mode SIGSTOP/SIGCONT signals cause a wakeup against __TASK_TRACED. If this races with the ptrace_unfreeze_traced at the end of a PTRACE_LISTEN, this can wake the task /after/ the check against __TASK_TRACED, but before the reset of state to TASK_TRACED. This causes it to

[PATCH] ptrace: fix PTRACE_LISTEN race corrupting task->state

In PT_SEIZED + LISTEN mode SIGSTOP/SIGCONT signals cause a wakeup against __TASK_TRACED. If this races with the ptrace_unfreeze_traced at the end of a PTRACE_LISTEN, this can wake the task /after/ the check against __TASK_TRACED, but before the reset of state to TASK_TRACED. This causes it to

Re: [PATCH V2] sched/fair: Fix that tasks are not constrained by cfs_b->quota on hotplug core, when hotplug core is offline and then online.

Jeehong Kim writes: > On 2016년 09월 23일 01:53, bseg...@google.com wrote: >> Jeehong Kim writes: >> Peter Zijlstra writes: > You forgot to Cc Ben, who gave you feedback on v1, which is rather poor > style. Also,

Re: [PATCH V2] sched/fair: Fix that tasks are not constrained by cfs_b->quota on hotplug core, when hotplug core is offline and then online.

Jeehong Kim writes: > On 2016년 09월 23일 01:53, bseg...@google.com wrote: >> Jeehong Kim writes: >> Peter Zijlstra writes: > You forgot to Cc Ben, who gave you feedback on v1, which is rather poor > style. Also, I don't see how kernel-janitors is relevant to this patch. >

Re: [PATCH 7/7 v3] sched: fix wrong utilization accounting when switching to fair class

Peter Zijlstra writes: > On Tue, Sep 20, 2016 at 09:59:08AM -0700, bseg...@google.com wrote: >> Peter Zijlstra writes: >> > Google has this patch-set replacing min_vruntime with an actual global >> > 0-lag, which greatly simplifies things. If only

Re: [PATCH 7/7 v3] sched: fix wrong utilization accounting when switching to fair class

Peter Zijlstra writes: > On Tue, Sep 20, 2016 at 09:59:08AM -0700, bseg...@google.com wrote: >> Peter Zijlstra writes: >> > Google has this patch-set replacing min_vruntime with an actual global >> > 0-lag, which greatly simplifies things. If only they'd post it sometime >> > :/ /me prods pjt

Re: [PATCH V2] sched/fair: Fix that tasks are not constrained by cfs_b->quota on hotplug core, when hotplug core is offline and then online.

Jeehong Kim writes: >>Peter Zijlstra writes: >> >>> You forgot to Cc Ben, who gave you feedback on v1, which is rather poor >>> style. Also, I don't see how kernel-janitors is relevant to this patch. >>> This is very much not a janitorial thing. >>>

Re: [PATCH V2] sched/fair: Fix that tasks are not constrained by cfs_b->quota on hotplug core, when hotplug core is offline and then online.

Jeehong Kim writes: >>Peter Zijlstra writes: >> >>> You forgot to Cc Ben, who gave you feedback on v1, which is rather poor >>> style. Also, I don't see how kernel-janitors is relevant to this patch. >>> This is very much not a janitorial thing. >>> >>> (also, why send it twice?) >>> >>> On

Re: [PATCH 7/7 v3] sched: fix wrong utilization accounting when switching to fair class

Peter Zijlstra writes: > On Fri, Sep 16, 2016 at 04:23:16PM +0200, Vincent Guittot wrote: >> On 16 September 2016 at 14:16, Peter Zijlstra wrote: > >> >> > Also, the normalize comment in dequeue_entity() worries me, 'someone' >> >> > didn't update

Re: [PATCH 7/7 v3] sched: fix wrong utilization accounting when switching to fair class

Peter Zijlstra writes: > On Fri, Sep 16, 2016 at 04:23:16PM +0200, Vincent Guittot wrote: >> On 16 September 2016 at 14:16, Peter Zijlstra wrote: > >> >> > Also, the normalize comment in dequeue_entity() worries me, 'someone' >> >> > didn't update that when he moved update_min_vruntime()

Re: [PATCH V2] sched/fair: Fix that tasks are not constrained by cfs_b->quota on hotplug core, when hotplug core is offline and then online.

Peter Zijlstra writes: > You forgot to Cc Ben, who gave you feedback on v1, which is rather poor > style. Also, I don't see how kernel-janitors is relevant to this patch. > This is very much not a janitorial thing. > > (also, why send it twice?) > > On Tue, Aug 30, 2016 at

Re: [PATCH V2] sched/fair: Fix that tasks are not constrained by cfs_b->quota on hotplug core, when hotplug core is offline and then online.

Peter Zijlstra writes: > You forgot to Cc Ben, who gave you feedback on v1, which is rather poor > style. Also, I don't see how kernel-janitors is relevant to this patch. > This is very much not a janitorial thing. > > (also, why send it twice?) > > On Tue, Aug 30, 2016 at 10:12:40PM +0900,

Re: [PATCH] sched/fair: Fix that tasks are not constrained by cfs_b->quota on hotplug core, when hotplug core is offline and then online.

Jeehong Kim writes: > In case that CONFIG_HOTPLUG_CPU and CONFIG_CFS_BANDWIDTH is turned on and > tasks in bandwidth controlled task group run on hotplug core, the tasks are > not controlled by cfs_b->quota when hotplug core is offline and then online. > The remaining

Re: [PATCH] sched/fair: Fix that tasks are not constrained by cfs_b->quota on hotplug core, when hotplug core is offline and then online.

Jeehong Kim writes: > In case that CONFIG_HOTPLUG_CPU and CONFIG_CFS_BANDWIDTH is turned on and > tasks in bandwidth controlled task group run on hotplug core, the tasks are > not controlled by cfs_b->quota when hotplug core is offline and then online. > The remaining tasks in task group

Re: [PATCH 4.4 043/146] sched/fair: Fix cfs_rq avg tracking underflow

Greg Kroah-Hartman writes: > 4.4-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Peter Zijlstra > > commit 8974189222159154c55f24ddad33e3613960521a upstream. > > As per commit: > >

Re: [PATCH 4.4 043/146] sched/fair: Fix cfs_rq avg tracking underflow

Greg Kroah-Hartman writes: > 4.4-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Peter Zijlstra > > commit 8974189222159154c55f24ddad33e3613960521a upstream. > > As per commit: > > b7fa30c9cc48 ("sched/fair: Fix

Re: [PATCH] sched/fair: do not announce throttled next buddy in dequeue_task_fair

Wanpeng Li writes: > 2016-07-15 1:54 GMT+08:00 : >> Wanpeng Li writes: >> >>> 2016-07-14 1:06 GMT+08:00 : Wanpeng Li writes: > 2016-07-13 1:25 GMT+08:00 :

Re: [PATCH] sched/fair: do not announce throttled next buddy in dequeue_task_fair

Wanpeng Li writes: > 2016-07-15 1:54 GMT+08:00 : >> Wanpeng Li writes: >> >>> 2016-07-14 1:06 GMT+08:00 : Wanpeng Li writes: > 2016-07-13 1:25 GMT+08:00 : >> Konstantin Khlebnikov writes: >> >>> On 11.07.2016 15:12, Xunlei Pang wrote: On 2016/07/11 at

Re: [PATCH] sched/fair: do not announce throttled next buddy in dequeue_task_fair

Wanpeng Li writes: > 2016-07-14 1:06 GMT+08:00 : >> Wanpeng Li writes: >> >>> 2016-07-13 1:25 GMT+08:00 : Konstantin Khlebnikov writes: > On 11.07.2016 15:12, Xunlei

Re: [PATCH] sched/fair: do not announce throttled next buddy in dequeue_task_fair

Wanpeng Li writes: > 2016-07-14 1:06 GMT+08:00 : >> Wanpeng Li writes: >> >>> 2016-07-13 1:25 GMT+08:00 : Konstantin Khlebnikov writes: > On 11.07.2016 15:12, Xunlei Pang wrote: >> On 2016/07/11 at 17:54, Wanpeng Li wrote: >>> Hi Konstantin, Xunlei, >>> 2016-07-11

Re: [PATCH] sched/fair: do not announce throttled next buddy in dequeue_task_fair

Wanpeng Li writes: > 2016-07-13 1:25 GMT+08:00 : >> Konstantin Khlebnikov writes: >> >>> On 11.07.2016 15:12, Xunlei Pang wrote: On 2016/07/11 at 17:54, Wanpeng Li wrote: > Hi Konstantin, Xunlei, > 2016-07-11

Re: [PATCH] sched/fair: do not announce throttled next buddy in dequeue_task_fair

Wanpeng Li writes: > 2016-07-13 1:25 GMT+08:00 : >> Konstantin Khlebnikov writes: >> >>> On 11.07.2016 15:12, Xunlei Pang wrote: On 2016/07/11 at 17:54, Wanpeng Li wrote: > Hi Konstantin, Xunlei, > 2016-07-11 16:42 GMT+08:00 Xunlei Pang : >> On 2016/07/11 at 16:22, Xunlei Pang

Re: [PATCH] sched/fair: do not announce throttled next buddy in dequeue_task_fair

Konstantin Khlebnikov writes: > On 11.07.2016 15:12, Xunlei Pang wrote: >> On 2016/07/11 at 17:54, Wanpeng Li wrote: >>> Hi Konstantin, Xunlei, >>> 2016-07-11 16:42 GMT+08:00 Xunlei Pang : On 2016/07/11 at 16:22, Xunlei Pang wrote: > On

Re: [PATCH] sched/fair: do not announce throttled next buddy in dequeue_task_fair

Konstantin Khlebnikov writes: > On 11.07.2016 15:12, Xunlei Pang wrote: >> On 2016/07/11 at 17:54, Wanpeng Li wrote: >>> Hi Konstantin, Xunlei, >>> 2016-07-11 16:42 GMT+08:00 Xunlei Pang : On 2016/07/11 at 16:22, Xunlei Pang wrote: > On 2016/07/11 at 15:25, Wanpeng Li wrote: >>

Re: [PATCH] sched/fair: initialize throttle_count for new task-groups lazily

Konstantin Khlebnikov writes: > On 16.06.2016 20:03, bseg...@google.com wrote: >> Konstantin Khlebnikov writes: >> >>> Cgroup created inside throttled group must inherit current throttle_count. >>> Broken throttle_count allows to nominate

Re: [PATCH] sched/fair: initialize throttle_count for new task-groups lazily

Konstantin Khlebnikov writes: > On 16.06.2016 20:03, bseg...@google.com wrote: >> Konstantin Khlebnikov writes: >> >>> Cgroup created inside throttled group must inherit current throttle_count. >>> Broken throttle_count allows to nominate throttled entries as a next buddy, >>> later this leads

Re: [PATCH] sched/fair: do not announce throttled next buddy in dequeue_task_fair

Konstantin Khlebnikov writes: > Hierarchy could be already throttled at this point. Throttled next > buddy could trigger null pointer dereference in pick_next_task_fair(). > > Signed-off-by: Konstantin Khlebnikov Reviewed-by: Ben Segall

Re: [PATCH] sched/fair: do not announce throttled next buddy in dequeue_task_fair

Konstantin Khlebnikov writes: > Hierarchy could be already throttled at this point. Throttled next > buddy could trigger null pointer dereference in pick_next_task_fair(). > > Signed-off-by: Konstantin Khlebnikov Reviewed-by: Ben Segall > Cc: Stable # v3.2+ > --- > kernel/sched/fair.c |

Re: [PATCH] sched/fair: initialize throttle_count for new task-groups lazily

Konstantin Khlebnikov writes: > Cgroup created inside throttled group must inherit current throttle_count. > Broken throttle_count allows to nominate throttled entries as a next buddy, > later this leads to null pointer dereference in pick_next_task_fair(). > > This

Re: [PATCH] sched/fair: initialize throttle_count for new task-groups lazily

Konstantin Khlebnikov writes: > Cgroup created inside throttled group must inherit current throttle_count. > Broken throttle_count allows to nominate throttled entries as a next buddy, > later this leads to null pointer dereference in pick_next_task_fair(). > > This patch initialize

Re: [RFC PATCH] sched: fix hierarchical order in rq->leaf_cfs_rq_list

Peter Zijlstra writes: > On Tue, May 24, 2016 at 11:55:10AM +0200, Vincent Guittot wrote: >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >> index 218f8e8..6d3fbf2 100644 >> --- a/kernel/sched/fair.c >> +++ b/kernel/sched/fair.c >> @@ -290,15 +290,31 @@ static

Re: [RFC PATCH] sched: fix hierarchical order in rq->leaf_cfs_rq_list

Peter Zijlstra writes: > On Tue, May 24, 2016 at 11:55:10AM +0200, Vincent Guittot wrote: >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >> index 218f8e8..6d3fbf2 100644 >> --- a/kernel/sched/fair.c >> +++ b/kernel/sched/fair.c >> @@ -290,15 +290,31 @@ static inline void

Re: [PATCH] sched/fair: Fix the wrong throttled clock time for cfs_rq_clock_task()

Xunlei Pang writes: > Two minor fixes for cfs_rq_clock_task(). > 1) If cfs_rq is currently being throttled, we need to subtract the cfs >throttled clock time. > > 2) Make "throttled_clock_task_time" update SMP unrelated. Now UP cases >need it as well. > >

Re: [PATCH] sched/fair: Fix the wrong throttled clock time for cfs_rq_clock_task()

Xunlei Pang writes: > Two minor fixes for cfs_rq_clock_task(). > 1) If cfs_rq is currently being throttled, we need to subtract the cfs >throttled clock time. > > 2) Make "throttled_clock_task_time" update SMP unrelated. Now UP cases >need it as well. > > Signed-off-by: Xunlei Pang >

Re: [PATCH 3/6] sched/fair: Change the variable to hold the number of periods to 32bit integer

Yuyang Du writes: > Now a period is about 1ms, so a 32-bit unsigned integer can approximately > hold a maximum of 49 (=2^32/1000/3600/24) days, which means it is big enough > and 64-bit is needless. > If a thread sleeps for 49 days and then wakes up this would be wrong...

Re: [PATCH 3/6] sched/fair: Change the variable to hold the number of periods to 32bit integer

Yuyang Du writes: > Now a period is about 1ms, so a 32-bit unsigned integer can approximately > hold a maximum of 49 (=2^32/1000/3600/24) days, which means it is big enough > and 64-bit is needless. > If a thread sleeps for 49 days and then wakes up this would be wrong... but it also would just

Re: [PATCH 1/6] sched/fair: Optimize sum computation with a lookup table

Yuyang Du writes: > __compute_runnable_contrib() uses a loop to compute sum, whereas a > table lookup can do it faster in a constant time. > > The program to generate the constants is located at: > Documentation/scheduler/sched-avg.txt > > Signed-off-by: Yuyang Du

Re: [PATCH 1/6] sched/fair: Optimize sum computation with a lookup table

Yuyang Du writes: > __compute_runnable_contrib() uses a loop to compute sum, whereas a > table lookup can do it faster in a constant time. > > The program to generate the constants is located at: > Documentation/scheduler/sched-avg.txt > > Signed-off-by: Yuyang Du > Reviewed-by: Morten

Re: [PATCH RESEND v2 6/6] sched/fair: Remove unconditionally inactive code

Yuyang Du writes: > The increased load resolution (fixed point arithmetic range) is > unconditionally deactivated with #if 0, so it is effectively broken. > > But the increased load range is still used somewhere (e.g., in Google), > so we keep this feature. The

Re: [PATCH RESEND v2 6/6] sched/fair: Remove unconditionally inactive code

Yuyang Du writes: > The increased load resolution (fixed point arithmetic range) is > unconditionally deactivated with #if 0, so it is effectively broken. > > But the increased load range is still used somewhere (e.g., in Google), > so we keep this feature. The reconciliation is we define >

Re: [PATCH RESEND v2 4/6] sched/fair: Remove scale_load_down() for load_avg

Yuyang Du writes: > Currently, load_avg = scale_load_down(load) * runnable%. The extra scaling > down of load does not make much sense, because load_avg is primarily THE > load and on top of that, we take runnable time into account. > > We therefore remove scale_load_down()

Re: [PATCH RESEND v2 4/6] sched/fair: Remove scale_load_down() for load_avg

Yuyang Du writes: > Currently, load_avg = scale_load_down(load) * runnable%. The extra scaling > down of load does not make much sense, because load_avg is primarily THE > load and on top of that, we take runnable time into account. > > We therefore remove scale_load_down() for load_avg. But we

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

Morten Rasmussen writes: > On Fri, Dec 11, 2015 at 11:18:56AM -0800, bseg...@google.com wrote: >> So uh yeah, my initial impression is "rip it out", but if being >> immediately-correct is important in the case of one task being most of >> the utilization, rather than when it is more evenly

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

Morten Rasmussen writes: > On Fri, Dec 11, 2015 at 11:18:56AM -0800, bseg...@google.com wrote: >> So uh yeah, my initial impression is "rip it out", but if being >> immediately-correct is important in the case of one task being most of >> the utilization, rather than

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

Dietmar Eggemann writes: > On 11/12/15 17:57, Morten Rasmussen wrote: >> On Fri, Dec 11, 2015 at 05:00:01PM +0300, Andrey Ryabinin wrote: >>> >>> >>> On 12/11/2015 04:36 PM, Peter Zijlstra wrote: On Fri, Dec 11, 2015 at 02:25:51PM +0100, Peter Zijlstra wrote: > On Fri, Dec 11, 2015 at

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

Andrey Ryabinin writes: > On 12/11/2015 04:36 PM, Peter Zijlstra wrote: >> On Fri, Dec 11, 2015 at 02:25:51PM +0100, Peter Zijlstra wrote: >>> On Fri, Dec 11, 2015 at 03:55:18PM +0300, Andrey Ryabinin wrote: Make 'r' 64-bit type to avoid overflow in 'r * LOAD_AVG_MAX' on 32-bit

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

Andrey Ryabinin writes: > On 12/11/2015 04:36 PM, Peter Zijlstra wrote: >> On Fri, Dec 11, 2015 at 02:25:51PM +0100, Peter Zijlstra wrote: >>> On Fri, Dec 11, 2015 at 03:55:18PM +0300, Andrey Ryabinin wrote: Make 'r' 64-bit type to avoid overflow in 'r *

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

Dietmar Eggemann writes: > On 11/12/15 17:57, Morten Rasmussen wrote: >> On Fri, Dec 11, 2015 at 05:00:01PM +0300, Andrey Ryabinin wrote: >>> >>> >>> On 12/11/2015 04:36 PM, Peter Zijlstra wrote: On Fri, Dec 11, 2015 at 02:25:51PM +0100, Peter Zijlstra wrote: >

Re: [PATCH v2 2/3] sched/fair: Move hot load_avg into its own cacheline

Waiman Long writes: > On 12/02/2015 03:02 PM, bseg...@google.com wrote: >> Waiman Long writes: >>> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h >>> index efd3bfc..e679895 100644 >>> --- a/kernel/sched/sched.h >>> +++ b/kernel/sched/sched.h >>> @@ -248,7 +248,12 @@ struct task_group

Re: [PATCH v2 2/3] sched/fair: Move hot load_avg into its own cacheline

Peter Zijlstra writes: > On Thu, Dec 03, 2015 at 09:56:02AM -0800, bseg...@google.com wrote: >> Peter Zijlstra writes: > >> > @@ -7402,11 +7405,12 @@ void __init sched_init(void) >> > #endif /* CONFIG_RT_GROUP_SCHED */ >> > >> > #ifdef CONFIG_CGROUP_SCHED >> > + task_group_cache =

Re: [PATCH v2 2/3] sched/fair: Move hot load_avg into its own cacheline

Peter Zijlstra writes: > I made this: > > --- > Subject: sched/fair: Move hot load_avg into its own cacheline > From: Waiman Long > Date: Wed, 2 Dec 2015 13:41:49 -0500 > [...] > @@ -7402,11 +7405,12 @@ void __init sched_init(void) > #endif /* CONFIG_RT_GROUP_SCHED */ > > #ifdef

  1   2   3   >