Re: [PATCH 3 of 4] KEXEC: Allocate crash structures in low memory

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 09/03/12 15:55, Jan Beulich wrote:
>>>> On 09.03.12 at 15:42, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> --- a/xen/drivers/char/console.c
>> +++ b/xen/drivers/char/console.c
>> @@ -596,7 +596,7 @@ void __init console_init_postirq(void)
>>          opt_conring_size = num_present_cpus() << (9 + xenlog_lower_thresh);
>>  
>>      order = get_order_from_bytes(max(opt_conring_size, conring_size));
>> -    while ( (ring = alloc_xenheap_pages(order, 0)) == NULL )
>> +    while ( (ring = alloc_xenheap_pages(order, MEMF_bits(crashinfo_maxaddr_bits))) == NULL )
>>      {
>>          BUG_ON(order == 0);
>>          order--;
> Did you note the loop here? Rather than shrinking the size, I think
> you ought to ignore the address limit as the first fallback option,
> in particular when the size was specified on the command line.
>
> Jan

Yes, but I disagree.  The default for crashinfo_maxaddr_bits is 64, so
most of the time, this change will have no functional effect.

The times when crashinfo_maxaddr_bits will change is either when the
user specifies "low_crashinfo=min/all" explicitly on the command line,
or implicitly specifies "low_crashinfo=min" by explicitly specifying
"crashinfo_maxaddr=$foo" on the command line.

At this point, I would say that the users request to have the console
ring in low memory overrides the size argument.

The usecase for low_crashinfo is with a 32bit crash kernel, at which
point a smaller console ring in lower memory is preferable to a larger
console ring that the crashdump kernel cant access.

If order gets to 0, one solution might be to then drop the location
restriction and try unrestricted from size again.  However, the point at
which you cant allocate a single page in lower memory is the point at
which you have bigger problems to worry about.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com