All of lore.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 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.