All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Mike Travis <travis@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Jack Steiner <steiner@sgi.com>,
	Lee Schermerhorn <lee.schermerhorn@hp.com>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] bitmap, irq: Add smp_affinity_list interface to /proc/irq
Date: Tue, 29 Mar 2011 17:56:14 -0700	[thread overview]
Message-ID: <20110329175614.0c41ae8c.akpm@linux-foundation.org> (raw)
In-Reply-To: <4D927E86.90400@sgi.com>

On Tue, 29 Mar 2011 17:51:18 -0700 Mike Travis <travis@sgi.com> wrote:

> > 
> > Also, the patch adds a new interface which duplicates an existing one,
> > only the formats are different, yes?  This is, of course, bad.
> > 
> > The only justification we've seen for being bad is "Manually adjusting
> > the smp_affinity for IRQ's becomes unwieldy when the cpu count is
> > large".  A more thorough description of how painful this is might help
> > motivate people to do bad things to the kernel.
> > 
> > Also, if it's just a matter of an alternative presentation of the data,
> > why not implement the desired user interface with a little userspace
> > tool then feed the results down into the existing kernel interface?
> > 
> 
> Setting smp affinity to cpus 256 to 263 would be:
> 
> echo 000000ff,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > smp_affinity
> 
> instead of:
> 
> echo 256-263 > smp_affinity_list
> 
> Think about what it looks like for cpus around say, 4088 to 4095.
> 
> We already have many alternate "list" interfaces:
> 
> /sys/devices/system/cpu/cpuX/indexY/shared_cpu_list
> /sys/devices/system/cpu/cpuX/topology/thread_siblings_list
> /sys/devices/system/cpu/cpuX/topology/core_siblings_list
> /sys/devices/system/node/nodeX/cpulist
> /sys/devices/pci***/***/local_cpulist
> 
> etc.
> 
> This just expands on that same philosophy.

You mean that if someone had written a stupid little tool to convert a
list of tuples into a bitmap, we wouldn't have needed to add all that
crap to the kernel?


  reply	other threads:[~2011-03-30  0:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-29 23:46 [PATCH] bitmap, irq: Add smp_affinity_list interface to /proc/irq Mike Travis
2011-03-29 23:56 ` Andrew Morton
2011-03-30  0:43   ` Andrew Morton
2011-03-30  0:51     ` Mike Travis
2011-03-30  0:56       ` Andrew Morton [this message]
2011-03-30  0:58         ` Mike Travis
2011-03-30  1:04         ` Mike Travis
2011-03-30  1:13           ` Andrew Morton
2011-03-31  7:37             ` KOSAKI Motohiro
2011-03-31 18:15               ` Mike Frysinger
2011-03-30  1:12 ` Mike Travis

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=20110329175614.0c41ae8c.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=lee.schermerhorn@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=steiner@sgi.com \
    --cc=tglx@linutronix.de \
    --cc=travis@sgi.com \
    /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.