All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Mel Gorman <mel@csn.ul.ie>
Cc: mingo@elte.hu, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	apw@shadowen.org
Subject: Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86 II
Date: Wed, 23 Jan 2008 14:48:09 +0100	[thread overview]
Message-ID: <200801231448.09514.andi@firstfloor.org> (raw)
In-Reply-To: <20080123112436.GF21455@csn.ul.ie>

On Wednesday 23 January 2008 12:24:36 Mel Gorman wrote:
> On (23/01/08 12:15), Andi Kleen didst pronounce:
> > Anyways from your earlier comments it sounds like you're trying to add
> > SRAT parsing to CONFIG_NUMAQ. Since that's redundant with the old
> > implementation it doesn't sound like a very useful thing to do.
>
> No, that would not be useful at all as it's redundant as you point out. The
> only reason to add it is if the Opteron box can figure out the CPU-to-node
> affinity. 

Assuming srat_32.c was fixed to not crash on Opteron it would likely
do that already without further changes.

> :| The patches applied so far are about increasing test coverage, not SRAT
> messing. 

Test coverage of the NUMAQ kernel?

If you wanted to increase test coverage of 32bit NUMA kernels the right
strategy would be to fix srat_32.

-Andi

WARNING: multiple messages have this Message-ID (diff)
From: Andi Kleen <andi@firstfloor.org>
To: Mel Gorman <mel@csn.ul.ie>
Cc: mingo@elte.hu, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	apw@shadowen.org
Subject: Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86 II
Date: Wed, 23 Jan 2008 14:48:09 +0100	[thread overview]
Message-ID: <200801231448.09514.andi@firstfloor.org> (raw)
In-Reply-To: <20080123112436.GF21455@csn.ul.ie>

On Wednesday 23 January 2008 12:24:36 Mel Gorman wrote:
> On (23/01/08 12:15), Andi Kleen didst pronounce:
> > Anyways from your earlier comments it sounds like you're trying to add
> > SRAT parsing to CONFIG_NUMAQ. Since that's redundant with the old
> > implementation it doesn't sound like a very useful thing to do.
>
> No, that would not be useful at all as it's redundant as you point out. The
> only reason to add it is if the Opteron box can figure out the CPU-to-node
> affinity. 

Assuming srat_32.c was fixed to not crash on Opteron it would likely
do that already without further changes.

> :| The patches applied so far are about increasing test coverage, not SRAT
> messing. 

Test coverage of the NUMAQ kernel?

If you wanted to increase test coverage of 32bit NUMA kernels the right
strategy would be to fix srat_32.

-Andi

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2008-01-23 13:48 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-18 15:35 [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86 Mel Gorman
2008-01-18 15:35 ` Mel Gorman
2008-01-18 15:35 ` [PATCH 1/2] Do not require CONFIG_HIGHMEM64G to set " Mel Gorman
2008-01-18 15:35   ` Mel Gorman
2008-01-18 16:17   ` Ingo Molnar
2008-01-18 16:17     ` Ingo Molnar
2008-01-18 15:36 ` [PATCH 2/2] Allow any x86 sub-architecture type to set CONFIG_NUMA Mel Gorman
2008-01-18 15:36   ` Mel Gorman
2008-01-18 16:17   ` Ingo Molnar
2008-01-18 16:17     ` Ingo Molnar
2008-01-19  6:35 ` [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86 Andi Kleen
2008-01-19  6:35   ` Andi Kleen
2008-01-19 16:07   ` Mel Gorman
2008-01-19 16:07     ` Mel Gorman
2008-01-22 12:14     ` Ingo Molnar
2008-01-22 12:14       ` Ingo Molnar
2008-01-22 12:29       ` Mel Gorman
2008-01-22 12:29         ` Mel Gorman
2008-01-22 15:39         ` Ingo Molnar
2008-01-22 15:39           ` Ingo Molnar
2008-01-22 13:33     ` Andi Kleen
2008-01-22 13:33       ` Andi Kleen
2008-01-23 10:28       ` Mel Gorman
2008-01-23 10:28         ` Mel Gorman
2008-01-23 10:45         ` Andi Kleen
2008-01-23 10:45           ` Andi Kleen
2008-01-23 10:57           ` Mel Gorman
2008-01-23 10:57             ` Mel Gorman
2008-01-23 11:11             ` Andi Kleen
2008-01-23 11:11               ` Andi Kleen
2008-01-23 11:15             ` [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86 II Andi Kleen
2008-01-23 11:15               ` Andi Kleen
2008-01-23 11:24               ` Mel Gorman
2008-01-23 11:24                 ` Mel Gorman
2008-01-23 13:48                 ` Andi Kleen [this message]
2008-01-23 13:48                   ` Andi Kleen
2008-01-23 14:15                   ` Mel Gorman
2008-01-23 14:15                     ` Mel Gorman
2008-01-21  0:38 ` [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86 KOSAKI Motohiro
2008-01-21  0:38   ` KOSAKI Motohiro
2008-01-21 14:35   ` Mel Gorman
2008-01-21 14:35     ` Mel Gorman
2008-01-21 14:49     ` Ingo Molnar
2008-01-21 14:49       ` Ingo Molnar
2008-01-21 16:27       ` Mel Gorman
2008-01-21 16:27         ` Mel Gorman
2008-01-23  2:04   ` KOSAKI Motohiro
2008-01-23  2:04     ` KOSAKI Motohiro
2008-01-23 10:22     ` Mel Gorman
2008-01-23 10:22       ` Mel Gorman
2008-01-24  3:19       ` KOSAKI Motohiro
2008-01-24  3:19         ` KOSAKI Motohiro
2008-01-23 10:23     ` Mel Gorman
2008-01-23 10:23       ` Mel Gorman
2008-01-26 14:10       ` KOSAKI Motohiro
2008-01-26 14:10         ` KOSAKI Motohiro
2008-01-26 17:10         ` KOSAKI Motohiro
2008-01-26 17:10           ` KOSAKI Motohiro
2008-01-26 17:18         ` Mel Gorman
2008-01-26 17:18           ` Mel Gorman
2008-01-27  6:54           ` KOSAKI Motohiro
2008-01-27  6:54             ` KOSAKI Motohiro
2008-01-28 15:02             ` Ingo Molnar
2008-01-28 15:02               ` Ingo Molnar
2008-01-29  2:57               ` KOSAKI Motohiro
2008-01-29  2:57                 ` KOSAKI Motohiro
2008-01-29 11:34             ` Mel Gorman
2008-01-29 11:34               ` Mel Gorman
2008-02-03  9:32               ` KOSAKI Motohiro

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=200801231448.09514.andi@firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=apw@shadowen.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=mingo@elte.hu \
    /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.