From: Peter Zijlstra <peterz@infradead.org>
To: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: mingo@elte.hu, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] sched: fair group: fix overflow(was: fix divide by zero)
Date: Thu, 12 Jun 2008 10:49:44 +0200 [thread overview]
Message-ID: <1213260584.31518.86.camel@twins> (raw)
In-Reply-To: <4850E192.3080804@cn.fujitsu.com>
On Thu, 2008-06-12 at 16:42 +0800, Lai Jiangshan wrote:
> Peter Zijlstra wrote:
> >
> > I think the same thing to do is limit the shares value to something
> > smaller instead of using an even more expensive divide.
> >
>
> yes, you are right!
>
> I found another bug about "the shares value is too large":
>
> pid1 and pid2 are set affinity to cpu#0
> pid1 is attached to cg1 and pid2 is attached to cg2
>
> if cg1/cpu.shares = 1024 cg2/cpu.shares = 2000000000
> then pid2 got 100% usage of cpu, and pid1 0%
>
> if cg1/cpu.shares = 1024 cg2/cpu.shares = 20000000000
> then pid2 got 0% usage of cpu, and pid1 100%
>
>
> And a weight of a cfs_rq is the sum of weights of which entities
> are queued on this cfs_rq, so the shares value should be limited
> to a smaller value.
Yeah, a lot of stuff will fall apart when weights grow too large, I
think somewhere the load balance code also assumes weight * NICE_0_LOAD
always fits in a long. So that immediately limits us to 32-10=22 bits
(on 32bit systems).
There might be other funnies..
> I think that (1UL << 18) is a good limited value:
> 1)it's not too large, we can create a lot of group before overflow
> 2)it's several times the weight value for nice=-19 (not too small)
Thanks!
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
> ---
> diff --git a/kernel/sched.c b/kernel/sched.c
> index bfb8ad8..fe1b6c7 100644
> --- a/kernel/sched.c
> +++ b/kernel/sched.c
> @@ -312,12 +312,15 @@ static DEFINE_SPINLOCK(task_group_lock);
> #endif
>
> /*
> - * A weight of 0, 1 or ULONG_MAX can cause arithmetics problems.
> + * A weight of 0 or 1 can cause arithmetics problems.
> + * A weight of a cfs_rq is the sum of weights of which entities
> + * are queued on this cfs_rq, so a weight of a entity should not be
> + * too large, so as the shares value of a task group.
> * (The default weight is 1024 - so there's no practical
> * limitation from this.)
> */
> #define MIN_SHARES 2
> -#define MAX_SHARES (ULONG_MAX - 1)
> +#define MAX_SHARES (1UL << 18)
>
> static int init_task_group_load = INIT_TASK_GROUP_LOAD;
> #endif
>
>
>
>
next prev parent reply other threads:[~2008-06-12 8:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-11 7:12 [PATCH] sched: fair group: fix divide by zero Lai Jiangshan
2008-06-11 7:15 ` Peter Zijlstra
2008-06-12 8:42 ` [PATCH 1/2] sched: fair group: fix overflow(was: fix divide by zero) Lai Jiangshan
2008-06-12 8:49 ` Peter Zijlstra [this message]
2008-06-12 12:22 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1213260584.31518.86.camel@twins \
--to=peterz@infradead.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.