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
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 set
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
l
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 to
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 reser
+ 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
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?
+ 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" su
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
Linux
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
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
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
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 obvio
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.
>
>
14 matches
Mail list logo
