Re: [PATCH] pseries: phyp dump: Variable size reserve space.
Yeah, that makes sense, I will shortly send a documentation patch for all the boot vars that I have added. Thanks for reminding. -Manish Linas Vepstas wrote: On 07/04/2008, Manish Ahuja [EMAIL PROTECTED] wrote: A small proposed change in the amount of reserve space we allocate during boot. Currently we reserve 256MB only. The proposed change does one of the 3 things. A. It checks to see if there is cmdline variable set and if found sets the value to it. OR B. It computes 5% of total ram and rounds it down to multiples of 256MB. AND C. Compares the rounded down value and returns larger of two values, the new computed value or 256MB. Again this is for large systems who have excess memory. [...] early_param(phyp_dump, early_phyp_dump_enabled); I'm pretty sure you will want to document this boot param in the documentation, as well as add a few words about why it might be interesting to users (i.e. that its for large systems...) --linas ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pseries: phyp dump: Variable size reserve space.
The aim is to have more flex space for the kernel on machines with more resources. Although the dump will be collected pretty fast and the memory released really early on allowing the machine to have the full memory available, this alleviates any issues that can be caused by having way too little memory on very very large systems during those few minutes. -Manish I think this would be an issue for distro kernels that have minimum requirements for memory above 256MB. It seems like a reasonable attempt to have good defaults. The user can always override it with boot args. I'm not sure where the exact numbers should be but the general statement that larger memory systems should have more memory to boot with seems like a good one. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pseries: phyp dump: Variable size reserve space.
On 07/04/2008, Manish Ahuja [EMAIL PROTECTED] wrote: A small proposed change in the amount of reserve space we allocate during boot. Currently we reserve 256MB only. The proposed change does one of the 3 things. A. It checks to see if there is cmdline variable set and if found sets the value to it. OR B. It computes 5% of total ram and rounds it down to multiples of 256MB. AND C. Compares the rounded down value and returns larger of two values, the new computed value or 256MB. Again this is for large systems who have excess memory. [...] early_param(phyp_dump, early_phyp_dump_enabled); I'm pretty sure you will want to document this boot param in the documentation, as well as add a few words about why it might be interesting to users (i.e. that its for large systems...) --linas ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pseries: phyp dump: Variable size reserve space.
Paul, The aim is to have more flex space for the kernel on machines with more resources. Although the dump will be collected pretty fast and the memory released really early on allowing the machine to have the full memory available, this alleviates any issues that can be caused by having way too little memory on very very large systems during those few minutes. -Manish Paul Mackerras wrote: Manish Ahuja writes: B. It computers 5% of total ram and rounds it down to multiples of 256MB. C. Compares the rounded down value and returns larger of 256MB or the new computed value. So if we have 10GB of memory or more we'll use reserve more than 256MB. What is the advantage of reserving more than 256MB of memory? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pseries: phyp dump: Variable size reserve space.
Olof Johansson wrote:
These make for some really long variable names and lines. I know from
experience, since I've picked unneccessary long driver names in the past
myself. :)
How about just naming the new variables reserve_bootvar, etc? The name
of the struct they're in makes it obvious what they're for.
Yeah, I guess thats a good suggestion. Will truncate it.
+static inline unsigned long phyp_dump_calculate_reserve_size(void)
+{
+unsigned long tmp;
+
+if (phyp_dump_info-phyp_dump_reserve_bootvar)
+return phyp_dump_info-phyp_dump_reserve_bootvar;
+
+/* divide by 20 to get 5% of value */
+tmp = lmb_end_of_DRAM();
+do_div(tmp, 20);
+
+/* round it down in multiples of 256 */
+tmp = tmp ~0x1FFF;
That's 512MB, isn't it?
No, its 5 % of memory and then rounded down to 256 MB multiples.
so if you 4GB its 256MB.
if you have 8 GB its 512 MB etc.
-Olof
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pseries: phyp dump: Variable size reserve space.
Olof Johansson wrote:
+static inline unsigned long phyp_dump_calculate_reserve_size(void)
+{
+unsigned long tmp;
+
+if (phyp_dump_info-phyp_dump_reserve_bootvar)
+return phyp_dump_info-phyp_dump_reserve_bootvar;
+
+/* divide by 20 to get 5% of value */
+tmp = lmb_end_of_DRAM();
+do_div(tmp, 20);
+
+/* round it down in multiples of 256 */
+tmp = tmp ~0x1FFF;
That's 512MB, isn't it?
My calculations in the example I gave in the last email were wrong.
In mentally did 10% instead of 5%. But the premise is same.
So assuming 5% of some memory is 400 MB, it rounds it down to 256MB etc.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pseries: phyp dump: Variable size reserve space.
On Wed, Apr 09, 2008 at 12:37:51PM -0500, Manish Ahuja wrote:
Olof Johansson wrote:
+static inline unsigned long phyp_dump_calculate_reserve_size(void)
+{
+ unsigned long tmp;
+
+ if (phyp_dump_info-phyp_dump_reserve_bootvar)
+ return phyp_dump_info-phyp_dump_reserve_bootvar;
+
+ /* divide by 20 to get 5% of value */
+ tmp = lmb_end_of_DRAM();
+ do_div(tmp, 20);
+
+ /* round it down in multiples of 256 */
+ tmp = tmp ~0x1FFF;
That's 512MB, isn't it?
My calculations in the example I gave in the last email were wrong.
In mentally did 10% instead of 5%. But the premise is same.
So assuming 5% of some memory is 400 MB, it rounds it down to 256MB etc.
But 0x1fff is 512MB, not 256MB. So you're rounding it down to a
multiple of 512MB.
-Olof
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pseries: phyp dump: Variable size reserve space.
Hmmm, You are possibly right. Okay I can check and fix that. -Manish Olof Johansson wrote: That's 512MB, isn't it? My calculations in the example I gave in the last email were wrong. In mentally did 10% instead of 5%. But the premise is same. So assuming 5% of some memory is 400 MB, it rounds it down to 256MB etc. But 0x1fff is 512MB, not 256MB. So you're rounding it down to a multiple of 512MB. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pseries: phyp dump: Variable size reserve space.
On Wed, Apr 09, 2008 at 01:43:51PM -0500, Manish Ahuja wrote: Hmmm, You are possibly right. Okay I can check and fix that. Well, fix the comments if you prefer, I just pointed out the discreptancy. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pseries: phyp dump: Variable size reserve space.
+ tmp = tmp ~0x1FFF; Note that this only works as you expect because the constant is signed here -- the extra zeroes do not magically make it a 64-bit number. So it goes 32-bit 0x1fff - 32-bit -0x2000 - 64-bit -0x2000. Please consider writing it with an L suffix, or UL even, to reduce trickiness and surprises if ever that number is changed. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pseries: phyp dump: Variable size reserve space.
Segher Boessenkool writes: + tmp = tmp ~0x1FFF; Note that this only works as you expect because the constant is signed here -- the extra zeroes do not magically make it a 64-bit number. So it goes 32-bit 0x1fff - 32-bit -0x2000 - 64-bit -0x2000. Huh? It's not big enough to be negative when considered as a 32-bit number... But yes, adding a UL would be a good idea. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pseries: phyp dump: Variable size reserve space.
+ tmp = tmp ~0x1FFF; Note that this only works as you expect because the constant is signed here -- the extra zeroes do not magically make it a 64-bit number. So it goes 32-bit 0x1fff - 32-bit -0x2000 - 64-bit -0x2000. Huh? It's not big enough to be negative when considered as a 32-bit number... 0x1fff isn't, right; and that makes it a signed int. Applying the complement operator to it turns it negative. And then the implicit cast (because tmp is 64-bit) makes it 64-bit, still the same negative value. Which is the expected result, but via a way too tricky (and fragile) path :-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pseries: phyp dump: Variable size reserve space.
Hi,
Just a few nitpicks, no comments on the functional parts:
On Mon, Apr 07, 2008 at 06:45:37PM -0500, Manish Ahuja wrote:
A small proposed change in the amount of reserve space we allocate during
boot.
Currently we reserve 256MB only.
The proposed change does one of the 3 things.
A. It checks to see if there is cmdline variable set and if found sets the
value to it. OR
B. It computes 5% of total ram and rounds it down to multiples of 256MB. AND
C. Compares the rounded down value and returns larger of two values, the new
computed value or 256MB.
...
+/* Look for phyp_dump_reserve_size= cmdline option */
+static int __init early_phyp_dump_reserve_size(char *p)
+{
+if (p)
+ phyp_dump_info-phyp_dump_reserve_bootvar = memparse(p, p);
[...]
@@ -24,8 +24,10 @@ struct phyp_dump {
/* Memory that is reserved during very early boot. */
unsigned long init_reserve_start;
unsigned long init_reserve_size;
- /* Check status during boot if dump supported, active present*/
+ /* cmd line options during boot */
+ unsigned long phyp_dump_reserve_bootvar;
unsigned long phyp_dump_at_boot;
+ /* Check status during boot if dump supported, active present*/
unsigned long phyp_dump_configured;
unsigned long phyp_dump_is_active;
/* store cpu hpte size */
These make for some really long variable names and lines. I know from
experience, since I've picked unneccessary long driver names in the past
myself. :)
How about just naming the new variables reserve_bootvar, etc? The name
of the struct they're in makes it obvious what they're for.
+static inline unsigned long phyp_dump_calculate_reserve_size(void)
+{
+ unsigned long tmp;
+
+ if (phyp_dump_info-phyp_dump_reserve_bootvar)
+ return phyp_dump_info-phyp_dump_reserve_bootvar;
+
+ /* divide by 20 to get 5% of value */
+ tmp = lmb_end_of_DRAM();
+ do_div(tmp, 20);
+
+ /* round it down in multiples of 256 */
+ tmp = tmp ~0x1FFF;
That's 512MB, isn't it?
-Olof
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
