From: Jeff Mahoney <jeffm@suse.com>
To: Jiri Kosina <jkosina@suse.cz>
Cc: Tejun Heo <tj@kernel.org>, Peter Zijlstra <peterz@infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Tony Luck <tony.luck@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
linux-ia64@vger.kernel.org
Subject: Re: Commit 34d76c41 causes linker errors on ia64 with NR_CPUS=4096
Date: Tue, 20 Oct 2009 14:49:17 +0000 [thread overview]
Message-ID: <4ADDCDED.6060706@suse.com> (raw)
In-Reply-To: <4ADDC69A.5000701@suse.com>
On 10/20/2009 10:18 AM, Jeff Mahoney wrote:
> On 10/20/2009 02:27 AM, Jiri Kosina wrote:
>> @@ -1627,11 +1623,10 @@ static int tg_shares_up(struct task_group *tg, void *data)
>> return 0;
>>
>> local_irq_save(flags);
>> - usd = &__get_cpu_var(update_shares_data);
>>
>> for_each_cpu(i, sched_domain_span(sd)) {
>> weight = tg->cfs_rq[i]->load.weight;
>> - usd->rq_weight[i] = weight;
>> + usd = *per_cpu_ptr(update_shares_data, i) = weight;
>>
>> /*
>> * If there are currently no tasks on the cpu pretend there
>
> I don't think this is what you want here.
>
> In the original version, usd is the percpu var using the current cpu. In
> your version, usd is the percpu var using i instead of the current cpu.
>
> I'll post my version of the patch shortly. I don't think keeping most of
> the original version is a bad thing. We can just allocate it dynamically
> instead.
This version fixes a build issue (__alignof__(unsigned long)) and fixes the
percpu lookup to be usd = percpu array pointer, usd[i] = actual variable.
-Jeff
From: Jiri Kosina <jkosina@suse.cz>
Subject: sched: move rq_weight data array out of .percpu
Commit 34d76c41 introduced percpu array update_shares_data, size of which
being proportional to NR_CPUS. Unfortunately this blows up ia64 for large
NR_CPUS configuration, as ia64 allows only 64k for .percpu section.
Fix this by allocating this array dynamically and keep only pointer to it
percpu.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
kernel/sched.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -1564,11 +1564,7 @@ static unsigned long cpu_avg_load_per_ta
#ifdef CONFIG_FAIR_GROUP_SCHED
-struct update_shares_data {
- unsigned long rq_weight[NR_CPUS];
-};
-
-static DEFINE_PER_CPU(struct update_shares_data, update_shares_data);
+unsigned long *update_shares_data;
static void __set_se_shares(struct sched_entity *se, unsigned long shares);
@@ -1578,12 +1574,12 @@ static void __set_se_shares(struct sched
static void update_group_shares_cpu(struct task_group *tg, int cpu,
unsigned long sd_shares,
unsigned long sd_rq_weight,
- struct update_shares_data *usd)
+ unsigned long *usd)
{
unsigned long shares, rq_weight;
int boost = 0;
- rq_weight = usd->rq_weight[cpu];
+ rq_weight = usd[cpu];
if (!rq_weight) {
boost = 1;
rq_weight = NICE_0_LOAD;
@@ -1618,7 +1614,7 @@ static void update_group_shares_cpu(stru
static int tg_shares_up(struct task_group *tg, void *data)
{
unsigned long weight, rq_weight = 0, shares = 0;
- struct update_shares_data *usd;
+ unsigned long *usd;
struct sched_domain *sd = data;
unsigned long flags;
int i;
@@ -1627,11 +1623,11 @@ static int tg_shares_up(struct task_grou
return 0;
local_irq_save(flags);
- usd = &__get_cpu_var(update_shares_data);
+ usd = per_cpu_ptr(update_shares_data, smp_processor_id());
for_each_cpu(i, sched_domain_span(sd)) {
weight = tg->cfs_rq[i]->load.weight;
- usd->rq_weight[i] = weight;
+ usd[i] = weight;
/*
* If there are currently no tasks on the cpu pretend there
@@ -9407,6 +9403,10 @@ void __init sched_init(void)
#endif /* CONFIG_USER_SCHED */
#endif /* CONFIG_GROUP_SCHED */
+#ifdef CONFIG_FAIR_GROUP_SCHED
+ update_shares_data = __alloc_percpu(nr_cpu_ids * sizeof(unsigned long),
+ __alignof__(unsigned long));
+#endif
for_each_possible_cpu(i) {
struct rq *rq;
--
Jeff Mahoney
SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Jeff Mahoney <jeffm@suse.com>
To: Jiri Kosina <jkosina@suse.cz>
Cc: Tejun Heo <tj@kernel.org>, Peter Zijlstra <peterz@infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Tony Luck <tony.luck@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
linux-ia64@vger.kernel.org
Subject: Re: Commit 34d76c41 causes linker errors on ia64 with NR_CPUS=4096
Date: Tue, 20 Oct 2009 10:49:17 -0400 [thread overview]
Message-ID: <4ADDCDED.6060706@suse.com> (raw)
In-Reply-To: <4ADDC69A.5000701@suse.com>
On 10/20/2009 10:18 AM, Jeff Mahoney wrote:
> On 10/20/2009 02:27 AM, Jiri Kosina wrote:
>> @@ -1627,11 +1623,10 @@ static int tg_shares_up(struct task_group *tg, void *data)
>> return 0;
>>
>> local_irq_save(flags);
>> - usd = &__get_cpu_var(update_shares_data);
>>
>> for_each_cpu(i, sched_domain_span(sd)) {
>> weight = tg->cfs_rq[i]->load.weight;
>> - usd->rq_weight[i] = weight;
>> + usd = *per_cpu_ptr(update_shares_data, i) = weight;
>>
>> /*
>> * If there are currently no tasks on the cpu pretend there
>
> I don't think this is what you want here.
>
> In the original version, usd is the percpu var using the current cpu. In
> your version, usd is the percpu var using i instead of the current cpu.
>
> I'll post my version of the patch shortly. I don't think keeping most of
> the original version is a bad thing. We can just allocate it dynamically
> instead.
This version fixes a build issue (__alignof__(unsigned long)) and fixes the
percpu lookup to be usd = percpu array pointer, usd[i] = actual variable.
-Jeff
From: Jiri Kosina <jkosina@suse.cz>
Subject: sched: move rq_weight data array out of .percpu
Commit 34d76c41 introduced percpu array update_shares_data, size of which
being proportional to NR_CPUS. Unfortunately this blows up ia64 for large
NR_CPUS configuration, as ia64 allows only 64k for .percpu section.
Fix this by allocating this array dynamically and keep only pointer to it
percpu.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
kernel/sched.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -1564,11 +1564,7 @@ static unsigned long cpu_avg_load_per_ta
#ifdef CONFIG_FAIR_GROUP_SCHED
-struct update_shares_data {
- unsigned long rq_weight[NR_CPUS];
-};
-
-static DEFINE_PER_CPU(struct update_shares_data, update_shares_data);
+unsigned long *update_shares_data;
static void __set_se_shares(struct sched_entity *se, unsigned long shares);
@@ -1578,12 +1574,12 @@ static void __set_se_shares(struct sched
static void update_group_shares_cpu(struct task_group *tg, int cpu,
unsigned long sd_shares,
unsigned long sd_rq_weight,
- struct update_shares_data *usd)
+ unsigned long *usd)
{
unsigned long shares, rq_weight;
int boost = 0;
- rq_weight = usd->rq_weight[cpu];
+ rq_weight = usd[cpu];
if (!rq_weight) {
boost = 1;
rq_weight = NICE_0_LOAD;
@@ -1618,7 +1614,7 @@ static void update_group_shares_cpu(stru
static int tg_shares_up(struct task_group *tg, void *data)
{
unsigned long weight, rq_weight = 0, shares = 0;
- struct update_shares_data *usd;
+ unsigned long *usd;
struct sched_domain *sd = data;
unsigned long flags;
int i;
@@ -1627,11 +1623,11 @@ static int tg_shares_up(struct task_grou
return 0;
local_irq_save(flags);
- usd = &__get_cpu_var(update_shares_data);
+ usd = per_cpu_ptr(update_shares_data, smp_processor_id());
for_each_cpu(i, sched_domain_span(sd)) {
weight = tg->cfs_rq[i]->load.weight;
- usd->rq_weight[i] = weight;
+ usd[i] = weight;
/*
* If there are currently no tasks on the cpu pretend there
@@ -9407,6 +9403,10 @@ void __init sched_init(void)
#endif /* CONFIG_USER_SCHED */
#endif /* CONFIG_GROUP_SCHED */
+#ifdef CONFIG_FAIR_GROUP_SCHED
+ update_shares_data = __alloc_percpu(nr_cpu_ids * sizeof(unsigned long),
+ __alignof__(unsigned long));
+#endif
for_each_possible_cpu(i) {
struct rq *rq;
--
Jeff Mahoney
SUSE Labs
next prev parent reply other threads:[~2009-10-20 14:49 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-18 22:28 Commit 34d76c41 causes linker errors on ia64 with NR_CPUS=4096 Jeff Mahoney
2009-10-20 2:02 ` Jiri Kosina
2009-10-20 2:02 ` Jiri Kosina
2009-10-20 4:57 ` Jiri Kosina
2009-10-20 4:57 ` Jiri Kosina
2009-10-20 5:21 ` Tejun Heo
2009-10-20 5:21 ` Tejun Heo
2009-10-20 5:58 ` Jiri Kosina
2009-10-20 5:58 ` Jiri Kosina
2009-10-20 6:12 ` Tejun Heo
2009-10-20 6:12 ` Tejun Heo
2009-10-20 6:14 ` Tejun Heo
2009-10-20 6:14 ` Tejun Heo
2009-10-20 6:27 ` Jiri Kosina
2009-10-20 6:27 ` Jiri Kosina
2009-10-20 14:18 ` Jeff Mahoney
2009-10-20 14:18 ` Jeff Mahoney
2009-10-20 14:49 ` Jeff Mahoney [this message]
2009-10-20 14:49 ` Jeff Mahoney
2009-10-21 6:11 ` Ingo Molnar
2009-10-21 6:11 ` Ingo Molnar
2009-10-21 15:19 ` Tejun Heo
2009-10-21 15:19 ` Tejun Heo
2009-10-21 22:11 ` Luck, Tony
2009-10-21 22:11 ` Luck, Tony
2009-10-22 14:49 ` Jiri Kosina
2009-10-22 14:49 ` Jiri Kosina
2009-10-22 14:53 ` Jeff Mahoney
2009-10-22 14:53 ` Jeff Mahoney
2009-10-22 22:24 ` Luck, Tony
2009-10-22 22:24 ` Luck, Tony
2009-10-23 7:51 ` Ingo Molnar
2009-10-23 7:51 ` Ingo Molnar
2009-10-23 12:30 ` Jiri Kosina
2009-10-23 12:30 ` Jiri Kosina
2009-10-26 16:38 ` Jiri Kosina
2009-10-26 16:38 ` Jiri Kosina
2009-10-26 20:16 ` Ingo Molnar
2009-10-26 20:16 ` Ingo Molnar
2009-10-27 10:03 ` Jiri Kosina
2009-10-27 10:03 ` Jiri Kosina
2009-10-27 10:52 ` Jiri Kosina
2009-10-27 10:52 ` Jiri Kosina
2009-10-20 6:15 ` Ingo Molnar
2009-10-20 6:15 ` Ingo Molnar
2009-10-20 6:26 ` Jiri Kosina
2009-10-20 6:26 ` Jiri Kosina
2009-10-20 6:35 ` Ingo Molnar
2009-10-20 6:35 ` Ingo Molnar
2009-10-20 7:11 ` Eric Dumazet
2009-10-20 7:11 ` Eric Dumazet
2009-10-20 7:39 ` Tejun Heo
2009-10-20 7:39 ` Tejun Heo
2009-10-20 7:12 ` Tejun Heo
2009-10-20 7:12 ` Tejun Heo
2009-10-20 7:17 ` Jiri Kosina
2009-10-20 7:17 ` Jiri Kosina
2009-10-20 7:36 ` Tejun Heo
2009-10-20 7:36 ` Tejun Heo
2009-10-20 13:08 ` Jeff Mahoney
2009-10-20 13:08 ` Jeff Mahoney
2009-10-20 13:43 ` Ingo Molnar
2009-10-20 13:43 ` Ingo Molnar
2009-10-20 13:57 ` Tejun Heo
2009-10-20 13:57 ` Tejun Heo
2009-10-20 13:58 ` Tejun Heo
2009-10-20 13:58 ` Tejun Heo
2009-10-21 6:43 ` Christoph Lameter
2009-10-21 6:43 ` Christoph Lameter
2009-10-20 9:21 ` Peter Zijlstra
2009-10-20 9:21 ` Peter Zijlstra
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=4ADDCDED.6060706@suse.com \
--to=jeffm@suse.com \
--cc=fenghua.yu@intel.com \
--cc=jkosina@suse.cz \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=tj@kernel.org \
--cc=tony.luck@intel.com \
/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.