public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mike Travis <travis@sgi.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ingo Molnar <mingo@elte.hu>,
	Rusty Russell <rusty@rustcorp.com.au>,
	linux-kernel@vger.kernel.org, Jack Steiner <steiner@sgi.com>
Subject: Re: [git pull] cpus4096 tree, part 3
Date: Sat, 03 Jan 2009 12:58:25 -0800	[thread overview]
Message-ID: <495FD171.4030502@sgi.com> (raw)
In-Reply-To: <alpine.LFD.2.00.0901031225020.3179@localhost.localdomain>

Linus Torvalds wrote:
> 
> On Sat, 3 Jan 2009, Ingo Molnar wrote:
>> ok. The pending regressions are all fixed now, and i've just finished my 
>> standard tests on the latest tree and all the tests passed fine.
> 
> Ok, pulled and pushed out.
> 
> Has anybody looked at what the stack size is with MAXSMP set with an 
> allyesconfig? And what areas are still problematic, if any? Are we going 
> to have some code-paths that still essentially have 1kB+ of stack space 
> just because they haven't been converted and still have the cpu mask on 
> stack?
> 
> 			Linus

Hi Linus,

Yes, I do periodically collect stats for memory and stack usage.  Here is
a recent stack summary (not "allyes", but most all trace/debug options
turned on).  It shows the stack growth from a 128 NR_CPUS config to a
MAXSMP (4096 NR_CPUS) config.  Most of the changes to correct these "stack
hogs" have been sitting in a queue until the changes affecting non-x86
architectures have been accepted (which you just did), though some are
because of new code from the merge activity.

Rusty has introduced a config option that disables the old cpumask_t
which really highlights where the offenders still are.  Ultimately,
that should prevent any new stack hogs from being introduced, but it
won't be settable until 2.6.30 time frame.

====== Stack (-l 500)
    1 - 128-defconfig
    2 - 4k-defconfig

  .1.    .2.    ..final..
    0  +1640 1640      .  acpi_cpufreq_target
    0  +1368 1368      .  cpufreq_add_dev
    0  +1344 1344      .  store_scaling_governor
    0  +1328 1328      .  store_scaling_min_freq
    0  +1328 1328      .  store_scaling_max_freq
    0  +1328 1328      .  cpufreq_update_policy
    0  +1328 1328      .  cpu_has_cpufreq
    0  +1048 1048      .  get_cur_val
    0  +1032 1032      .  local_cpus_show
    0  +1032 1032      .  local_cpulist_show
    0  +1024 1024      .  pci_bus_show_cpuaffinity
    0   +808 808      .  cpuset_write_resmask
    0   +736 736      .  update_flag
    0   +648 648      .  init_intel_cacheinfo
    0   +640 640      .  cpuset_attach
    0   +584 584      .  shmem_getpage
    0   +584 584      .  __percpu_alloc_mask
    0   +552 552      .  smp_call_function_many
    0   +536 536      .  pci_device_probe
    0   +536 536      .  native_flush_tlb_others
    0   +536 536      .  cpuset_common_file_read
    0   +520 520      .  show_related_cpus
    0   +520 520      .  show_affected_cpus
    0   +520 520      .  get_measured_perf
    0   +520 520      .  flush_tlb_page
    0   +520 520      .  cpuset_can_attach
    0   +512 512      .  flush_tlb_mm
    0   +512 512      .  flush_tlb_current_task
    0   +512 512      .  find_lowest_rq
    0   +512 512      .  acpi_processor_ffh_cstate_probe

====== Text/Data ()

Overall memory reservation looks like this:

      .1.       .2.    ..final..
  5799936     +4096   5804032 +0.07%  TextSize
  3772416   +139264   3911680 +3.69%  DataSize
  8822784  +1234944  10057728   +13%  BssSize
  2445312   +794624   3239936   +32%  InitSize
  1884160     +4096   1888256 +0.22%  PerCPU
   143360   +708608    851968  +494%  OtherSize
 22867968  +2885632  25753600  +112%  Totals


I will update these with the latest changes (and use a
allyesconfig config) and post them again soon.

Thanks,
Mike

  parent reply	other threads:[~2009-01-03 20:58 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-01  1:19 [PULL] cpumask tree Rusty Russell
2009-01-02 20:06 ` Linus Torvalds
2009-01-02 20:38   ` Ingo Molnar
2009-01-02 23:31     ` Linus Torvalds
2009-01-03 19:38       ` [git pull] cpus4096 tree, part 3 Ingo Molnar
2009-01-03 20:28         ` Linus Torvalds
2009-01-03 20:36           ` Ingo Molnar
2009-01-03 20:56             ` Linus Torvalds
2009-01-03 21:58               ` Ingo Molnar
2009-01-04  3:35               ` Rusty Russell
2009-01-04  4:28                 ` Mike Travis
2009-01-03 21:38             ` Ingo Molnar
2009-01-03 22:00               ` Linus Torvalds
2009-01-03 22:37                 ` Ingo Molnar
2009-01-05  1:14                   ` Nick Piggin
2009-01-05  1:16                     ` Nick Piggin
2009-01-26 19:00                       ` Andrew Morton
2009-01-26 19:09                         ` Linus Torvalds
2009-01-26 19:30                           ` Andrew Morton
2009-01-26 20:09                         ` Ingo Molnar
2009-01-26 20:44                           ` Andrew Morton
     [not found]                             ` <604427e00901261312w23a1f0f5y61fc5c6cc70297fb@mail.gmail.com>
2009-01-26 23:21                               ` Ingo Molnar
2009-01-26 23:44                                 ` Andrew Morton
2009-01-07 17:30                     ` Ingo Molnar
2009-01-03 20:58           ` Mike Travis [this message]
2009-01-03  7:20     ` [PULL] cpumask tree Rusty Russell
2009-01-03 10:52       ` Ingo Molnar
2009-01-03 11:59         ` [PATCH] ia64: cpumask fix for is_affinity_mask_valid() Ingo Molnar
2009-01-03 12:19           ` [PATCH] cpumask: convert RCU implementations, fix Ingo Molnar
2009-01-04  3:43           ` [PATCH] ia64: cpumask fix for is_affinity_mask_valid() Rusty Russell
2009-01-04  4:20             ` Mike Travis
2009-01-04 12:38               ` Ingo Molnar
2009-01-03 14:58         ` [PULL] cpumask tree Mike Travis
2009-01-03 15:06           ` Ingo Molnar
2009-01-03 15:31             ` Mike Travis
2009-01-03 15:47               ` Ingo Molnar
2009-01-03 15:52                 ` Mike Travis
2009-01-03 16:00                 ` Ingo Molnar
2009-01-03 16:09                   ` Mike Travis
2009-01-03 16:42                     ` Ingo Molnar
2009-01-03 16:48                       ` Mike Travis
2009-01-03 17:45                     ` Ingo Molnar
2009-01-03 18:13                       ` Ingo Molnar
2009-01-03 18:14                       ` Mike Travis
2009-01-03  0:23   ` Rusty Russell
2009-01-08 19:10 ` David Daney

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=495FD171.4030502@sgi.com \
    --to=travis@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rusty@rustcorp.com.au \
    --cc=steiner@sgi.com \
    --cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox