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
next prev 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