[Top] [All Lists]

Re: MIPS: Sibyte: Remove irritating printk from set_affinity

To: "Maciej W. Rozycki" <>
Subject: Re: MIPS: Sibyte: Remove irritating printk from set_affinity
From: Ralf Baechle <>
Date: Fri, 12 Jun 2009 13:41:50 +0100
In-reply-to: <>
Original-recipient: rfc822;
References: <S20023844AbZFIMUh/> <>
User-agent: Mutt/1.5.18 (2008-05-17)
On Tue, Jun 09, 2009 at 05:07:15PM +0100, Maciej W. Rozycki wrote:
> From: "Maciej W. Rozycki" <>
> Date: Tue, 9 Jun 2009 17:07:15 +0100 (WEST)
> To:
> Subject: Re: MIPS: Sibyte: Remove irritating printk from set_affinity
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> On Tue, 9 Jun 2009, wrote:
> > set_affinity() will be called with cpui masks, which have more than one
> > cpu set.  Instead of generating noise we now select the first set
> > cpu and use that for setting affinity.  The printk was being triggered
> > frequently by recent distributions running on recent kernels.
>  For the record: I don't think it relates to a distribution being "recent" 
> at all -- the noise happens with my board with recent kernels and does not 
> with older ones even though the userland is always the same.  Something 
> must have changed within the kernel itself and it may be worth 
> investigating what, why and whether it is legitimate.  I fear the change 
> may be papering over some bug elsewhere.

You're right - I realized that after having hit the commit button ...

I don't think there really is a kernel bug there.  The function we changed
is free to reject arguments.  The reason why the Sibyte kernel has this
check is that its hardware routing capabilities allow it to route an
interrupt to _all_ CPUs of a certain set while this Linux API assumes an
interrupt to be sent to just _one_ of the CPUs contained in the set.  On
Sibyte this would result in usually all CPUs taking an interrupt exception.
Only one can take the interrupt lock for that interrupt; the other will
return from exception without having done any useful work.  While it may
give the lowest latencies this certainly involves a high overhead.  Yes,
a closer look into why things are being done this way is probably justified.


<Prev in Thread] Current Thread [Next in Thread>