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