All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Travis <travis@sgi.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Christoph Lameter <cl@linux-foundation.org>,
	Jack Steiner <steiner@sgi.com>,
	linux-kernel@vger.kernel.org, Paul Jackson <pj@sgi.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Adrian Bunk <bunk@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 1/8] cpumask: Replace cpumask_of_cpu with cpumask_of_cpu_ptr
Date: Wed, 23 Jul 2008 10:45:18 -0700	[thread overview]
Message-ID: <48876E2E.4000508@sgi.com> (raw)
In-Reply-To: <200807202003.31526.rusty@rustcorp.com.au>

Rusty Russell wrote:
...
>> Another thought I had is perhaps cpumask.h should define something that
>> indicates a "huge NR_CPUS count" that is used globally to trigger things
>> like kmalloc of cpumask variables, instead of declaring them on the
>> stack...?  Or (as has been discussed in the past), maybe a new cpumask_t
>> type will be needed?
> 
> AFAICT the final answer has to be a get_cpu_mask()/put_cpu_mask(), which 
> sleeps and doesn't nest (so we can use a pool allocator).  Of course, that 
> kind of analysis is non-trivial, so I suggest that's not for this merge 
> window...
> 
> Want me to try something and see if it boots?
> Rusty.

Hi Rusty,

There are a number of occasions where a function declares a temporary cpumask_t
variable on the stack to hold (say) current->cpus_allowed.  I tried a couple of
options early on to a.) reserve one or two cpumask_t variables in the task
struct; and b.) reserve one or two cpumask_t variables per cpu.  Both had weird
consequences in some usages and since 4096 is *only* 512 bytes, it didn't seem
worth the effort.  Our next iteration will have NR_CPUS=16384 and therefore
removing all stack declared cpumask_t variables is highly desirable.

Your idea of a pool allocator is very interesting... ;-)

Thanks,
Mike

  parent reply	other threads:[~2008-07-23 17:45 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-15 21:14 [PATCH 0/8] cpumask: Replace/optimize cpumask_of_cpu & cpumask_t operations Mike Travis
2008-07-15 21:14 ` [PATCH 1/8] cpumask: Replace cpumask_of_cpu with cpumask_of_cpu_ptr Mike Travis
2008-07-18  5:30   ` Rusty Russell
2008-07-18 13:43     ` Mike Travis
2008-07-20 10:03       ` Rusty Russell
2008-07-23 11:20         ` Ingo Molnar
2008-07-23 11:23           ` Ingo Molnar
2008-07-23 14:26             ` Mike Travis
2008-07-24  0:46               ` Rusty Russell
2008-07-23 14:16           ` Mike Travis
2008-07-23 17:45         ` Mike Travis [this message]
2008-07-15 21:14 ` [PATCH 2/8] cpumask: Optimize cpumask_of_cpu in arch/x86/kernel/io_apic_64.c Mike Travis
2008-07-15 21:14 ` [PATCH 3/8] cpumask: Optimize cpumask_of_cpu in arch/x86/kernel/ldt.c Mike Travis
2008-07-15 21:14 ` [PATCH 4/8] cpumask: Optimize cpumask_of_cpu in drivers/misc/sgi-xp/xpc_main.c Mike Travis
2008-07-16 11:17   ` Dean Nelson
2008-07-15 21:14 ` [PATCH 5/8] cpumask: Optimize cpumask_of_cpu in kernel/time/tick-common.c Mike Travis
2008-07-15 21:14 ` [PATCH 6/8] cpumask: Optimize cpumask_of_cpu in lib/smp_processor_id.c Mike Travis
2008-07-18 20:33   ` Ingo Molnar
2008-07-18 20:35     ` Ingo Molnar
2008-07-18 22:36       ` Mike Travis
2008-07-15 21:14 ` [PATCH 7/8] cpumask: Provide a generic set of CPUMASK_ALLOC macros Mike Travis
2008-07-16  6:41   ` Bert Wesarg
2008-07-16 12:25     ` Mike Travis
2008-07-16 13:01       ` Mike Travis
2008-07-15 21:14 ` [PATCH 8/8] cpumask: Use optimized CPUMASK_ALLOC macros in the centrino_target Mike Travis
2008-07-18 20:04 ` [PATCH 0/8] cpumask: Replace/optimize cpumask_of_cpu & cpumask_t operations Ingo Molnar

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=48876E2E.4000508@sgi.com \
    --to=travis@sgi.com \
    --cc=akpm@linux-foundation.org \
    --cc=bunk@kernel.org \
    --cc=cl@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=pj@sgi.com \
    --cc=rusty@rustcorp.com.au \
    --cc=steiner@sgi.com \
    --cc=tglx@linutronix.de \
    /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.