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" <firstname.lastname@example.org>
> > Date: Tue, 9 Jun 2009 17:07:15 +0100 (WEST)
> > To: email@example.com
> > Subject: Re: MIPS: Sibyte: Remove irritating printk from set_affinity
> > Content-Type: TEXT/PLAIN; charset=US-ASCII
> > On Tue, 9 Jun 2009, firstname.lastname@example.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.