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>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	rusty@rustcorp.com.au, linux-kernel@vger.kernel.org,
	Jack Steiner <steiner@sgi.com>
Subject: Re: 2.6.29-rc1 does not boot
Date: Sun, 11 Jan 2009 15:19:18 -0800	[thread overview]
Message-ID: <496A7E76.2050507@sgi.com> (raw)
In-Reply-To: <496A451C.5030400@sgi.com>

Mike Travis wrote:
> Ingo Molnar wrote:
...
>> Mike, most of the work_on_cpu() patches you did so far were rather 
>> problematic. Especially something like cpufreq can run rather early during 
>> bootup or during suspend/resume, so i'm not sure it's correct to rely on 
>> keventd for it.
>>
>> I dont see anything particularly wrong in the commit itself - but 
>> obviously it causes this boot hang - if the bug is not found we'll revert 
>> it .
> 
> All of these are low use functions, primarily used when bringing up
> cpus.  So reverting the patches does not have a big effect on the stack
> size problem.

Btw, we're looking great with stack space.  This is using the 'allyesconfig'
config with NR_CPUS=4096, MAX_NUMNODES=512, and 128-allyesconfig having
NR_CPUS=128, MAX_NUMNODES=64.

====== Stack (-l 500)

    1 - 128-allyesconfig
    2 - allyesconfig

  .1.   .2.  .delta.
    0   600   600      .  shmem_getpage
    0   600   600      .  powernowk8_target
    0   584   584      .  powernowk8_cpu_init
    0   584   584      .  __percpu_alloc_mask
    0   552   552      .  smp_call_function_many
    0   536   536      .  reload_store
    0   528   528      .  get_cur_freq
    0   528   528      .  check_supported_cpu
    0   520   520      .  powernowk8_get
    0   520   520      .  microcode_write
    0   520   520      .  microcode_init_cpu

In Data space we've still got a couple of memory hogs:

====== Data (-l 500)

    1 - 128-allyesconfig
    2 - allyesconfig

    .1.      .2.  .delta.
  16384   524288  +507904 +3100%  boot_pageset(.bss)	[1]
  23816   483080  +459264 +1928%  kmalloc_caches(.data.cacheline_aligned) [2]
  17408   132096  +114688  +658%  irq_info(.bss)	[3]
  17408   132096  +114688  +658%  irq_bindcount(.bss)	[3]
   1020   131072  +130052 +12750%  apic_version(.bss)	[4]
   3072    98304   +95232 +3100%  ucode_cpu_info(.bss)	[5]
   2048    65536   +63488 +3100%  kgdb_info(.bss)	[5]
   5120    40960   +35840  +700%  node_devices(.bss)	[6]
   5216    36952   +31736  +608%  iter(.bss)		[???]
   6404    33284   +26880  +419%  e820_saved(.bss)	[7]
   6404    33284   +26880  +419%  e820(.bss)		[7]
   1040    33280   +32240 +3100%  cpu_bit_bitmap(.rodata) [8]
   1064    32808   +31744 +2983%  max_tr(.bss)		[9]
   1064    32808   +31744 +2983%  global_trace(.bss)	[9]
   1024    32768   +31744 +3100%  fcoe_percpu(.bss)	[10]

[1]: very hard to fix, might be able to use early per_cpu_alloc when available
[2]: can be fixed when early per_cpu_alloc available
[3]: sized by NR_IRQS which can be fixed now
[4]: currently apic_version[MAX_APICS] which is a very sparsely filled array
[5]: sized by NR_CPUS, can be dynamically allocated
[6]: sized by MAX_NUMNODES, also can be dynamically allocated
[7]: sized by MAX_NUMNODES, not so easily modified
[8]: will fix when cpumask_size() is sized by nr_cpu_ids instead of NR_CPUS
[9]: struct trace_array has an NR_CPUS array component
[10]: pointer list sized by NR_CPUS


Overall, the percentages are good:

====== Text/Data ()

    1 - 128-allyesconfig
    2 - allyesconfig

       .1.       .2.  .delta.
  33490944  33499136      +8192 +0.02%  TextSize
  45527040  45598720     +71680 +0.16%  DataSize
  11315200  12685312   +1370112   +12%  BssSize
   3436544   4231168    +794624   +23%  InitSize [1]
   1904640   1910784      +6144 +0.32%  PerCPU
    333824    794624    +460800  +138%  OtherSize

[1]: remember, this space is "given back" after system initializes.

Here the section detail:

====== Sections (-l 500)

    1 - 128-allyesconfig
    2 - allyesconfig

        .1.       .2.  .delta.
   11316152  12685496    +1369344   +12%  .bss
      32384    491648     +459264 +1418%  .data.cacheline_aligned
  370195151 370555424     +360273 +0.10%  .debug_info
    7358485   7445195      +86710 +1.18%  .debug_abbrev
   23003987  23045427      +41440 +0.18%  .rodata
   21248744  21281904      +33160 +0.16%  .data
   43877348  43890141      +12793 +0.03%  .debug_loc
      66728     76984      +10256   +15%  .data.read_mostly
   33491529  33498553       +7024 +0.02%  .text
   26088048  26094032       +5984 +0.02%  .debug_ranges
    1904288   1910176       +5888 +0.31%  .data.percpu
   19530974  19532151       +1177 +0.01%  .debug_line
     153072    152432        -640 -0.42%  __param
     836911    837706        +795 +0.09%  .init.text

  reply	other threads:[~2009-01-11 23:19 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-11 14:55 2.6.29-rc1 does not boot Dieter Ries
2009-01-11 15:19 ` Ingo Molnar
2009-01-11 15:30   ` Dieter Ries
2009-01-11 15:35     ` Ingo Molnar
2009-01-11 15:41       ` Dieter Ries
2009-01-11 18:50       ` Dieter Ries
2009-01-11 19:02         ` Mike Travis
2009-01-11 19:30           ` Dieter Ries
2009-01-12 10:00           ` Ingo Molnar
2009-01-12 17:53             ` Mike Travis
2009-01-12 18:55               ` Ingo Molnar
2009-01-15  0:54             ` Rusty Russell
2009-01-11 19:02         ` Ingo Molnar
2009-01-11 19:14           ` Mike Travis
2009-01-11 23:19             ` Mike Travis [this message]
2009-01-12  1:01             ` H. Peter Anvin
2009-01-12 11:22         ` Maciej Rutecki
2009-01-12 11:26           ` Ingo Molnar
2009-01-12 11:28             ` Maciej Rutecki
2009-01-12 12:10             ` Dieter Ries
2009-01-12 12:21               ` Ingo Molnar
2009-01-12 16:37                 ` Dieter Ries
2009-01-12 18:59                   ` Ingo Molnar
2009-01-13  4:45                     ` Michal Jaegermann
2009-01-12 17:22             ` 2.6.29-rc1 does not boot and fails to resume Rafael J. Wysocki
2009-01-14  1:16             ` 2.6.29-rc1 does not boot Rusty Russell
2009-01-14 11:30               ` Ingo Molnar
2009-01-14 12:47               ` Dieter Ries
2009-01-15 20:01         ` Mike Travis
2009-01-15 21:03           ` Dieter Ries
2009-01-15 21:48             ` Maciej Rutecki
2009-01-15 21:54               ` Mike Travis
2009-01-15 23:04                 ` Maciej Rutecki
2009-01-15 23:31                   ` Mike Travis
2009-01-15 21:54             ` Mike Travis
2009-01-15 23:02               ` Dieter Ries
2009-01-15 23:30                 ` 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=496A7E76.2050507@sgi.com \
    --to=travis@sgi.com \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --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.