[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> 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...

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.