All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: MIPS: Sibyte: Remove irritating printk from set_affinity
Date: Fri, 12 Jun 2009 13:41:50 +0100	[thread overview]
Message-ID: <20090612124150.GB21878@linux-mips.org> (raw)
In-Reply-To: <alpine.LFD.1.10.0906091702530.8994@ftp.linux-mips.org>

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.

  Ralf

  reply	other threads:[~2009-06-12 12:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <S20023844AbZFIMUh/20090609122037Z+10394@ftp.linux-mips.org>
2009-06-09 16:07 ` MIPS: Sibyte: Remove irritating printk from set_affinity Maciej W. Rozycki
2009-06-12 12:41   ` Ralf Baechle [this message]
2009-06-12 23:13     ` Ralf Baechle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090612124150.GB21878@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=linux-mips@linux-mips.org \
    --cc=macro@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.