Re: [Xen-devel] [PATCH] x86/cpu: Reduce boot-time logspam

["Liu, Jinsong" <jinsong.liu@xxxxxxxxx>]

Jan Beulich wrote:
>>>> On 16.01.14 at 12:44, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>>> wrote: 
>> --- a/xen/arch/x86/cpu/mcheck/mce.c
>> +++ b/xen/arch/x86/cpu/mcheck/mce.c
>> @@ -729,8 +729,8 @@ void mcheck_init(struct cpuinfo_x86 *c, bool_t
>>      bsp)  { enum mcheck_type inited = mcheck_none;
>> 
>> -    if (mce_disabled == 1) {
>> -        dprintk(XENLOG_INFO, "MCE support disabled by bootparam\n");
>> +    if (bsp && mce_disabled == 1) {
>> +        printk(XENLOG_INFO "MCE support disabled by bootparam\n");
> 
> While I'm fine with this, ...
> 
>> --- a/xen/arch/x86/cpu/mwait-idle.c
>> +++ b/xen/arch/x86/cpu/mwait-idle.c
>> @@ -540,7 +540,7 @@ static int mwait_idle_cpu_init(struct
>>              notifier_block *nfb, state = MWAIT_HINT2CSTATE(hint) + 1;
>>              substate = MWAIT_HINT2SUBSTATE(hint);
>> 
>> -            if (state > max_cstate) {
>> +            if (cpu == 0 && state > max_cstate) {
>>                      printk(PREFIX "max C-state %u reached\n", max_cstate);  
>>                         break;
>>              }
>> @@ -552,7 +552,7 @@ static int mwait_idle_cpu_init(struct
>>              notifier_block *nfb, if (substate >= num_substates)
>>                      continue;
>> 
>> -            if (dev->count >= ACPI_PROCESSOR_MAX_POWER) {
>> +            if (cpu == 0 && dev->count >= ACPI_PROCESSOR_MAX_POWER) {
>>                      printk(PREFIX "max C-state count of %u reached\n",
>>                             ACPI_PROCESSOR_MAX_POWER);
>>                      break;
> 
> ... I object to both of these: There's no reason why the C-state
> count could differ between CPUs. Hence I'd accept these being
> guarded so they each get printed just once, but tying this to
> CPU0 is wrong. And then, adding the CPU number would be a
> natural thing to do.
> 
> Also, with this being a clone of Linux code (with which I sync from
> time to time), I'd really expect such changes to go through there.
> Of course, if you see the messages with Xen but not with a suitable
> Linux equivalent, then we'd have to look into why you see them...
> 

Agree, and, root cause 'Discovered when testing Xen-4.4-rc2 on an Haswell SDP 
platform with some MCE and Cstate quirks' is real point.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel