Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1280808 > unrolled thread

Re: [PATCH] x86, mtrr: mark range_new in mtrr_calc_range_state() as __initdata

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] x86, mtrr: mark range_new in mtrr_calc_range_state() as __initdata Rasmus Villemoes <linux@rasmusvillemoes.dk> - 2015-12-01 13:00 +0100
    Re: [PATCH] x86, mtrr: mark range_new in mtrr_calc_range_state() as  __initdata Ingo Molnar <mingo@kernel.org> - 2015-12-01 17:20 +0100
      [PATCH v2] x86, mtrr: mark range_new in mtrr_calc_range_state() as __initdata Rasmus Villemoes <linux@rasmusvillemoes.dk> - 2015-12-01 21:50 +0100
        [tip:x86/mm] x86/mm/mtrr: Mark the 'range_new'   static variable in mtrr_calc_range_state() as __initdata tip-bot for Rasmus Villemoes <tipbot@zytor.com> - 2015-12-04 13:00 +0100

#1280808 — Re: [PATCH] x86, mtrr: mark range_new in mtrr_calc_range_state() as __initdata

On Fri, Nov 27 2015, Ingo Molnar <mingo@kernel.org> wrote:

> * Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote:
>
>> range_new doesn't seem to be used after init. It is only passed to
>> memset, sum_ranges, memcmp and x86_get_mtrr_mem_range, the latter of
>> which also only passes it on to various *range* library functions. So
>> mark it __initdata to free up an extra page after init.
>> 
>> nr_range_new is unconditionally assigned to before it is read, so
>> there's no point in having it static.
>> 
>> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
>> ---
>>  arch/x86/kernel/cpu/mtrr/cleanup.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c b/arch/x86/kernel/cpu/mtrr/cleanup.c
>> index 70d7c93f4550..b1a9ad366f67 100644
>> --- a/arch/x86/kernel/cpu/mtrr/cleanup.c
>> +++ b/arch/x86/kernel/cpu/mtrr/cleanup.c
>> @@ -593,9 +593,9 @@ mtrr_calc_range_state(u64 chunk_size, u64 gran_size,
>>  		      unsigned long x_remove_base,
>>  		      unsigned long x_remove_size, int i)
>>  {
>> -	static struct range range_new[RANGE_NUM];
>> +	static struct range range_new[RANGE_NUM] __initdata;
>>  	unsigned long range_sums_new;
>> -	static int nr_range_new;
>> +	int nr_range_new;
>>  	int num_reg;
>>  
>>  	/* Convert ranges to var ranges state: */
>
> So this static variable actually surprised me - I never realized it was there - 
> and it's not some simple 'once' flag, but something that is essential semantics.
>
> So marking it __initdata is correct, but please also move it out of function local 
> variables scope, into file scope - and name it properly as well, like 
> mtrr_new_range[] or so?

I can certainly do that, but isn't the usual preference to keep the
scope as small as possible? IOW, why do you want to make this a
file-scoped variable?

Also, I don't really see how the 'static' has 'essential semantics'. AFAICT, the
contents are wiped on every invocation of mtrr_calc_range_state, so the
only reason it's static is to avoid blowing the stack.

Rasmus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1280999 — Re: [PATCH] x86, mtrr: mark range_new in mtrr_calc_range_state() as __initdata

* Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote:

> On Fri, Nov 27 2015, Ingo Molnar <mingo@kernel.org> wrote:
> 
> > * Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote:
> >
> >> range_new doesn't seem to be used after init. It is only passed to
> >> memset, sum_ranges, memcmp and x86_get_mtrr_mem_range, the latter of
> >> which also only passes it on to various *range* library functions. So
> >> mark it __initdata to free up an extra page after init.
> >> 
> >> nr_range_new is unconditionally assigned to before it is read, so
> >> there's no point in having it static.
> >> 
> >> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> >> ---
> >>  arch/x86/kernel/cpu/mtrr/cleanup.c | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c b/arch/x86/kernel/cpu/mtrr/cleanup.c
> >> index 70d7c93f4550..b1a9ad366f67 100644
> >> --- a/arch/x86/kernel/cpu/mtrr/cleanup.c
> >> +++ b/arch/x86/kernel/cpu/mtrr/cleanup.c
> >> @@ -593,9 +593,9 @@ mtrr_calc_range_state(u64 chunk_size, u64 gran_size,
> >>  		      unsigned long x_remove_base,
> >>  		      unsigned long x_remove_size, int i)
> >>  {
> >> -	static struct range range_new[RANGE_NUM];
> >> +	static struct range range_new[RANGE_NUM] __initdata;
> >>  	unsigned long range_sums_new;
> >> -	static int nr_range_new;
> >> +	int nr_range_new;
> >>  	int num_reg;
> >>  
> >>  	/* Convert ranges to var ranges state: */
> >
> > So this static variable actually surprised me - I never realized it was there - 
> > and it's not some simple 'once' flag, but something that is essential semantics.
> >
> > So marking it __initdata is correct, but please also move it out of function local 
> > variables scope, into file scope - and name it properly as well, like 
> > mtrr_new_range[] or so?
> 
> I can certainly do that, but isn't the usual preference to keep the scope as 
> small as possible? IOW, why do you want to make this a file-scoped variable?

The preference is to keep code readable and obvious, and this one wasn't: relevant 
state/data was hidden via a non-commented local static variable.

> Also, I don't really see how the 'static' has 'essential semantics'. AFAICT, the 
> contents are wiped on every invocation of mtrr_calc_range_state, so the only 
> reason it's static is to avoid blowing the stack.

So this was another property that wasn't obvious from the limited context I saw in 
the patch, i.e. the variable definition. Another solution would be to add a 
comment explaining that this is a local variable to keep kernel stack size down, 
and explain why it's safe to do that.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1281206 — [PATCH v2] x86, mtrr: mark range_new in mtrr_calc_range_state() as __initdata

range_new doesn't seem to be used after init. It is only passed to
memset, sum_ranges, memcmp and x86_get_mtrr_mem_range, the latter of
which also only passes it on to various *range* library functions. So
mark it __initdata to free up an extra page after init.

Its contents are wiped at every call to mtrr_calc_range_state(), so it
being static is not about preserving state between calls, but simply
to avoid a 4k+ stack frame. While there, add a comment explaining this
and why it's safe.

We could also mark nr_range_new as __initdata, but since it's just a
single int and also doesn't carry state between calls (it is
unconditionally assigned to before it is read), we might as well make
it an ordinary automatic variable.

Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
Something like this, perhaps?

v2: Add comment on range_new, per Ingo.

 arch/x86/kernel/cpu/mtrr/cleanup.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c b/arch/x86/kernel/cpu/mtrr/cleanup.c
index 70d7c93f4550..0d98503c2245 100644
--- a/arch/x86/kernel/cpu/mtrr/cleanup.c
+++ b/arch/x86/kernel/cpu/mtrr/cleanup.c
@@ -593,9 +593,16 @@ mtrr_calc_range_state(u64 chunk_size, u64 gran_size,
 		      unsigned long x_remove_base,
 		      unsigned long x_remove_size, int i)
 {
-	static struct range range_new[RANGE_NUM];
+	/*
+	 * range_new should really be an automatic variable, but
+	 * putting 4096 bytes on the stack is frowned upon, to put it
+	 * mildly. It is safe to make it a static __initdata variable,
+	 * since mtrr_calc_range_state is only called during init and
+	 * there's no way it will call itself recursively.
+	 */
+	static struct range range_new[RANGE_NUM] __initdata;
 	unsigned long range_sums_new;
-	static int nr_range_new;
+	int nr_range_new;
 	int num_reg;
 
 	/* Convert ranges to var ranges state: */
-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1283736 — [tip:x86/mm] x86/mm/mtrr: Mark the 'range_new' static variable in mtrr_calc_range_state() as __initdata

Commit-ID:  c332813b51cbe807d539bb059b81235abf1e3fdd
Gitweb:     http://git.kernel.org/tip/c332813b51cbe807d539bb059b81235abf1e3fdd
Author:     Rasmus Villemoes <linux@rasmusvillemoes.dk>
AuthorDate: Tue, 1 Dec 2015 21:44:50 +0100
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Fri, 4 Dec 2015 09:11:28 +0100

x86/mm/mtrr: Mark the 'range_new' static variable in mtrr_calc_range_state() as __initdata

'range_new' doesn't seem to be used after init. It is only passed
to memset(), sum_ranges(), memcmp() and x86_get_mtrr_mem_range(), the
latter of which also only passes it on to various *range*
library functions.

So mark it __initdata to free up an extra page after init.

Its contents are wiped at every call to mtrr_calc_range_state(),
so it being static is not about preserving state between calls,
but simply to avoid a 4k+ stack frame. While there, add a
comment explaining this and why it's safe.

We could also mark nr_range_new as __initdata, but since it's
just a single int and also doesn't carry state between calls (it
is unconditionally assigned to before it is read), we might as
well make it an ordinary automatic variable.

Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Toshi Kani <toshi.kani@hp.com>
Link: http://lkml.kernel.org/r/1449002691-20783-1-git-send-email-linux@rasmusvillemoes.dk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/x86/kernel/cpu/mtrr/cleanup.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c b/arch/x86/kernel/cpu/mtrr/cleanup.c
index 70d7c93..0d98503 100644
--- a/arch/x86/kernel/cpu/mtrr/cleanup.c
+++ b/arch/x86/kernel/cpu/mtrr/cleanup.c
@@ -593,9 +593,16 @@ mtrr_calc_range_state(u64 chunk_size, u64 gran_size,
 		      unsigned long x_remove_base,
 		      unsigned long x_remove_size, int i)
 {
-	static struct range range_new[RANGE_NUM];
+	/*
+	 * range_new should really be an automatic variable, but
+	 * putting 4096 bytes on the stack is frowned upon, to put it
+	 * mildly. It is safe to make it a static __initdata variable,
+	 * since mtrr_calc_range_state is only called during init and
+	 * there's no way it will call itself recursively.
+	 */
+	static struct range range_new[RANGE_NUM] __initdata;
 	unsigned long range_sums_new;
-	static int nr_range_new;
+	int nr_range_new;
 	int num_reg;
 
 	/* Convert ranges to var ranges state: */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web