Re: [PATCH 00/12] cpumask: reduce stack pressure from local/passed cpumask variables v2

All of lore.kernel.org
 help / color / mirror / Atom feed

From: Mike Travis <travis@sgi.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/12] cpumask: reduce stack pressure from local/passed cpumask variables v2
Date: Wed, 26 Mar 2008 08:53:27 -0700	[thread overview]
Message-ID: <47EA7177.8010605@sgi.com> (raw)
In-Reply-To: <20080326061824.GB18301@elte.hu>

Ingo Molnar wrote:
> * Mike Travis <travis@sgi.com> wrote:
> 
>> Modify usage of cpumask_t variables to use pointers as much as 
>> possible.
> 
> hm, why is there no minimal patch against -git that does nothing but 
> introduces the new pointer based generic APIs (without using them) - 
> such as set_cpus_allowed_ptr(), etc.? Once that is upstream all the 
> remaining changes can trickle one arch and one subsystem at a time, and 
> once that's done, the old set_cpus_allowed() can be removed. This is far 
> more manageable than one large patch.
> 
> and the cpumask_of_cpu() change should be Kconfig based initially - once 
> all arches have moved to it (or even sooner) we can remove that.
> 
> 	Ingo

Yes, good idea!  I'll see about dividing them up.  Though 99% seems to
be in generic kernel code (kernel/sched.c is by far the biggest user.)

There is one function pointer in a struct that would need an additional entry
if we keep both interfaces.

Thanks,
Mike

WARNING: multiple messages have this Message-ID (diff)

From: Mike Travis <travis@sgi.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/12] cpumask: reduce stack pressure from local/passed cpumask variables v2
Date: Wed, 26 Mar 2008 08:53:27 -0700	[thread overview]
Message-ID: <47EA7177.8010605@sgi.com> (raw)
In-Reply-To: <20080326061824.GB18301@elte.hu>

Ingo Molnar wrote:
> * Mike Travis <travis@sgi.com> wrote:
> 
>> Modify usage of cpumask_t variables to use pointers as much as 
>> possible.
> 
> hm, why is there no minimal patch against -git that does nothing but 
> introduces the new pointer based generic APIs (without using them) - 
> such as set_cpus_allowed_ptr(), etc.? Once that is upstream all the 
> remaining changes can trickle one arch and one subsystem at a time, and 
> once that's done, the old set_cpus_allowed() can be removed. This is far 
> more manageable than one large patch.
> 
> and the cpumask_of_cpu() change should be Kconfig based initially - once 
> all arches have moved to it (or even sooner) we can remove that.
> 
> 	Ingo

Yes, good idea!  I'll see about dividing them up.  Though 99% seems to
be in generic kernel code (kernel/sched.c is by far the biggest user.)

There is one function pointer in a struct that would need an additional entry
if we keep both interfaces.

Thanks,
Mike

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

next prev parent reply	other threads:[~2008-03-26 15:53 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-26  1:38 [PATCH 00/12] cpumask: reduce stack pressure from local/passed cpumask variables v2 Mike Travis
2008-03-26  1:38 ` Mike Travis
2008-03-26  1:38 ` [PATCH 01/12] cpumask: Convert cpumask_of_cpu to allocated array v2 Mike Travis
2008-03-26  1:38   ` Mike Travis
2008-03-26  1:38 ` [PATCH 02/12] cpumask: pass pointer to cpumask for set_cpus_allowed() v2 Mike Travis
2008-03-26  1:38   ` Mike Travis
2008-03-26  1:38 ` [PATCH 03/12] cpumask: reduce stack pressure in sched_affinity Mike Travis
2008-03-26  1:38   ` Mike Travis
2008-03-26  1:38 ` [PATCH 04/12] cpumask: pass cpumask by reference to acpi-cpufreq Mike Travis
2008-03-26  1:38   ` Mike Travis
2008-03-26  2:15   ` Dave Jones
2008-03-26  2:15     ` Dave Jones
2008-03-26  1:38 ` [PATCH 05/12] init: move large array from stack to _initdata section Mike Travis
2008-03-26  1:38   ` Mike Travis
2008-03-26  1:38 ` [PATCH 06/12] cpumask: create pointer to node_to_cpumask array element v2 Mike Travis
2008-03-26  1:38   ` Mike Travis
2008-03-26  1:38 ` [PATCH 07/12] cpumask: reduce stack usage in SD_x_INIT initializers Mike Travis
2008-03-26  1:38   ` Mike Travis
2008-03-26  1:38 ` [PATCH 08/12] cpumask: pass temp cpumask variables in init_sched_build_groups Mike Travis
2008-03-26  1:38   ` Mike Travis
2008-03-26  1:38 ` [PATCH 09/12] sched: fix memory leak in build_sched_domains Mike Travis
2008-03-26  1:38   ` Mike Travis
2008-03-26  1:38 ` [PATCH 10/12] cpumask: reduce stack usage " Mike Travis
2008-03-26  1:38   ` Mike Travis
2008-03-26  1:38 ` [PATCH 11/12] cpumask: reduce stack pressure in cpu_coregroup_map v2 Mike Travis
2008-03-26  1:38   ` Mike Travis
2008-03-26  1:38 ` [PATCH 12/12] cpu/node mask: reduce stack usage using MASK_NONE, MASK_ALL Mike Travis
2008-03-26  1:38   ` Mike Travis
2008-03-26  6:18 ` [PATCH 00/12] cpumask: reduce stack pressure from local/passed cpumask variables v2 Ingo Molnar
2008-03-26  6:18   ` Ingo Molnar
2008-03-26 15:53   ` Mike Travis [this message]
2008-03-26 15:53     ` 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=47EA7177.8010605@sgi.com \
    --to=travis@sgi.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@elte.hu \
    /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.