public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: jbarnes@sgi.com (Jesse Barnes)
To: linux-ia64@vger.kernel.org
Subject: Re: 2.5.72 for ia64 released
Date: Fri, 20 Jun 2003 18:53:03 +0000	[thread overview]
Message-ID: <marc-linux-ia64-105613529920818@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105605890319553@msgid-missing>

On Fri, Jun 20, 2003 at 11:49:33AM -0700, David Mosberger wrote:
> >>>>> On Fri, 20 Jun 2003 11:45:19 -0700, jbarnes@sgi.com (Jesse Barnes) said:
> 
>   >> I thought the DISCONTIGMEM support is making assumptions about the
>   >> physical memory layout.  If this is still true, DISCONTIGMEM and
>   >> GENERIC cannot go together.
> 
>   Jesse> No, the discontig patch I posted earlier should allow this.  We've
>   Jesse> tested it quite a bit in 2.4.
> 
> I'm not questioning whether it works on SGI, what I'm asking is
> whether it will work on _all_ possible NUMA architectures, or just on
> SN2.

Yeah, that's what I meant.  Jack's patch to 2.4 has been tested on sn2,
DIG, zx1, NEC, and Bull machines, as a generic kernel for the first
three at least (don't know what NEC and Bull did for their testing).

>   >> I suspect it would be more preferable if you could make it possible
>   >> for a non-NUMA kernel to boot on your machine.
> 
>   Jesse> That might be nice, but I'd rather have CONFIG_GENERIC turn on
>   Jesse> CONFIG_NUMA.  It shouldn't get in the way of non-NUMA machines...
> 
> What I worry about is that some distributions may end up shipping
> GENERIC kernels, with no easy way to build an optimized kernel.  It's
> reasonable to expect highend customers to build their own kernels, but
> I don't think that's quite as reasonable to expect the same from
> someone who buys a workstation.

So you're worried about the performance penalty of turning on NUMA for
generic kernels?

Jesse

  parent reply	other threads:[~2003-06-20 18:53 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-19 21:39 2.5.72 for ia64 released David Mosberger
2003-06-20 11:38 ` Andreas Schwab
2003-06-20 17:11 ` Jesse Barnes
2003-06-20 17:47 ` Sam Ravnborg
2003-06-20 18:01 ` David Mosberger
2003-06-20 18:35 ` Jesse Barnes
2003-06-20 18:41 ` David Mosberger
2003-06-20 18:45 ` Jesse Barnes
2003-06-20 18:49 ` David Mosberger
2003-06-20 18:50 ` Jesse Barnes
2003-06-20 18:53 ` Jesse Barnes [this message]
2003-06-20 19:02 ` David Mosberger
2003-06-20 19:07 ` Jesse Barnes
2003-06-20 19:44 ` Andreas Schwab
2003-06-20 19:49 ` Jesse Barnes
2003-06-20 19:51 ` Andreas Schwab
2003-06-20 19:56 ` Jesse Barnes
2003-06-20 20:03 ` Alex Tsariounov
2003-06-20 20:06 ` David Mosberger
2003-06-20 20:25 ` Andreas Schwab
2003-06-20 20:28 ` Jesse Barnes
2003-06-20 20:34 ` David Mosberger
2003-06-20 20:39 ` Jesse Barnes
2003-06-20 20:40 ` Andreas Schwab
2003-06-20 20:50 ` David Mosberger
2003-06-20 20:51 ` Sam Ravnborg
2003-06-20 21:04 ` Jack Steiner
2003-06-20 21:06 ` David Mosberger
2003-06-20 21:21 ` Jesse Barnes

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=marc-linux-ia64-105613529920818@msgid-missing \
    --to=jbarnes@sgi.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