Re: MIPS: Sibyte: Remove irritating printk from set_affinity

[Ralf Baechle <ralf@linux-mips.org>]

On Fri, Jun 12, 2009 at 01:41:50PM +0100, Ralf Baechle wrote:

> On Tue, Jun 09, 2009 at 05:07:15PM +0100, Maciej W. Rozycki wrote:
> > From: "Maciej W. Rozycki" <macro@linux-mips.org>
> > Date: Tue, 9 Jun 2009 17:07:15 +0100 (WEST)
> > To: linux-mips@linux-mips.org
> > Subject: Re: MIPS: Sibyte: Remove irritating printk from set_affinity
> > Content-Type: TEXT/PLAIN; charset=US-ASCII
> > 
> > On Tue, 9 Jun 2009, linux-mips@linux-mips.org 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.

And now there is a cleaner way to deal with this sort of issue, see
d5dedd4507d307eb3f35f21b6e16f336fdc0d82a.  The printk itself was a bug
in itself.  When do people learn that printk isn't stderr.

  Ralf