public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Bob Picco <bob.picco@hp.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [PATCH 0/4] V4 ia64 SPARSEMEM
Date: Mon, 26 Sep 2005 23:35:32 +0000	[thread overview]
Message-ID: <20050926233532.GL16066@localhost.localdomain> (raw)
In-Reply-To: <20050922161418.GW16066@localhost.localdomain>

luck wrote:	[Mon Sep 26 2005, 04:40:36PM EDT]
> >This patchset differs very little from V3. It requires SPARSEMEM EXTREME
> >patches which are in 2.6.14-rcX.
> 
> Bob,
> 
> Can you provide a bit more of a write up on what this change means?
> Which config options have gone, what the new ones, and what are the
> rules that determine what's legal.  The help options in Kconfig don't
> seem very helpful here.
I'm assuming you refer to the config changes in arch/ia64/Kconfig. Well the
new ones are documented in mm/Kconfig.  If that documentation is inadequate,
then I can attempt to supply more.
> 
> I think it would be a good idea to bundle a set of changes to the
> default config files along with this change ... which means we should
> have a discussion on what are the sensible defaults out of the new
> array of options, and which of the non-default options are still
> popular enough that I should make sure to test build them in my
> regular scripts.  Right now this whole change is a close to being
> a no-op as none of the default configs enables SPARSEMEM.
This is true and just about universally true for other arches with SPARSEMEM
enabled. I took a quick look and only i386 selects SPARSEMEM for NUMA.
I couldn't find any default config files with SPARSEMEM.  I think the objective
was for more soak time before defaulting to SPARSEMEM. Also just a few
arches have SPARSEMEM support.  Dave Hansen can possibly fill in my gaps.
> 
> So can you throw together a straw-man proposal for each of the
> default configs (maybe SGI can provide the sn2 version)?  I'm assuming
> here that SPARSEMEM is going to be the preferred choice for some
> system(s) ... I'm just not sure which.
We could be more aggressive than other arches but still follow the cautious
path.  I'm reluctant to suggest this but adding a couple of default 
configuration files with SPARSEMEM might be useful.  Perhaps 
sn2_defconfig_sparsemem and defconfig_sparsemem. 

Certainly a more aggressive strategy would be any config with DISCONTIG,
VIRTUAL_MEM_MAP and  NUMA be change to SPARSEMEM and NUMA.  We've only
have performance numbers done for a large Altix configuration and rx2600.
Tiger, rx2600, Altix and HP Architecture Simulator for NUMA are the only known
machines tested with SPARSEMEM. It's doubtful there would be issues but 
doesn't seem like a good strategy.

Should you think we won't get sufficient test converage without some default
configuration files, then I'd suggest the two mentioned about be introduced.
Long term should SPARSEMEM become the default and DISCONTIG+VIRTUAL_MEM_MAP
be obsoleted then we could remove the config files.
> 
> -Tony

bob

  parent reply	other threads:[~2005-09-26 23:35 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-22 16:14 [PATCH 0/4] V4 ia64 SPARSEMEM Bob Picco
2005-09-26 20:40 ` Luck, Tony
2005-09-26 22:23 ` Luck, Tony
2005-09-26 23:35 ` Bob Picco [this message]
2005-09-26 23:40 ` Bob Picco
2005-09-27  0:03 ` Luck, Tony
2005-09-27  1:20 ` David Mosberger-Tang
2005-09-27  4:53 ` Yasunori Goto
2005-09-27 12:45 ` Jack Steiner
2005-09-27 14:09 ` Bob Picco
2005-09-27 14:10 ` Bob Picco
2005-09-27 19:22 ` Bob Picco
2005-09-27 22:00 ` Luck, Tony

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=20050926233532.GL16066@localhost.localdomain \
    --to=bob.picco@hp.com \
    --cc=linux-ia64@vger.kernel.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