[PATCH 0/8] AMD opteron mm config numa etc

[PATCH 0/8] AMD opteron mm config numa etc

[Yinghai Lu]

please check some amd opteron related mmconf and numa patches

could make up for system that system have acpi problem
or still can mmconf and numa when acpi=off

YH

Re: [PATCH 0/8] AMD opteron mm config numa etc

[Ingo Molnar]

* Yinghai Lu <Yinghai.Lu@Sun.COM> wrote:

> please check some amd opteron related mmconf and numa patches
> 
> could make up for system that system have acpi problem or still can 
> mmconf and numa when acpi=off

Greg, any deep objections against these patches? (other than that they 
need a good amount of testing) I personally think that the more 
independent the kernel is of the whims of the BIOS, the better ...

	Ingo

Re: [PATCH 0/8] AMD opteron mm config numa etc

[Jeff Garzik]

Yinghai Lu wrote:
> please check some amd opteron related mmconf and numa patches
> 
> could make up for system that system have acpi problem
> or still can mmconf and numa when acpi=off

ACK for my parts (stuff associated with PCI domain support on x86)

	Jeff

Re: [PATCH 0/8] AMD opteron mm config numa etc

[Greg KH]

On Tue, Feb 19, 2008 at 12:23:22PM +0100, Ingo Molnar wrote:
> 
> * Yinghai Lu <Yinghai.Lu@Sun.COM> wrote:
> 
> > please check some amd opteron related mmconf and numa patches
> > 
> > could make up for system that system have acpi problem or still can 
> > mmconf and numa when acpi=off
> 
> Greg, any deep objections against these patches? (other than that they 
> need a good amount of testing) I personally think that the more 
> independent the kernel is of the whims of the BIOS, the better ...

No objection from me, other than they need a LOT of testing.  Oh, and
the networking patch is still wrong, and the poster has been told this
numerous times, which makes me wonder how well the pci bridge patch was
tested...

thanks,

greg k-h

Re: [PATCH 0/8] AMD opteron mm config numa etc

[Ingo Molnar]

* Greg KH <greg@kroah.com> wrote:

> > > could make up for system that system have acpi problem or still 
> > > can mmconf and numa when acpi=off
> > 
> > Greg, any deep objections against these patches? (other than that 
> > they need a good amount of testing) I personally think that the more 
> > independent the kernel is of the whims of the BIOS, the better ...
> 
> No objection from me, other than they need a LOT of testing. [...]

ok - have queued it up for v2.6.26. Note: Andrew might get grumpy when 
your PCI tree starts changing nearby places in arch/x86/pci again and it 
clashes with these changes in x86.git - in that case please pick up the 
full lot from x86.git#testing and carry it in the PCI tree. (or, 
alternatively, send me any trivial, arch/x86-only PCI bits to 
x86.git#testing so that we can keep it and test it all in a single place 
- whichever approach is more convenient to you)

> [...] Oh, and the networking patch is still wrong, and the poster has 
> been told this numerous times, which makes me wonder how well the pci 
> bridge patch was tested...

i think the optimization should be more correct now than in the past, 
its purpose and dependencies just have not been communicated fully. 
We'll get there eventually :-)

	Ingo

Re: [PATCH 0/8] AMD opteron mm config numa etc

[Andrew Morton]

On Wed, 20 Feb 2008 07:37:52 +0100 Ingo Molnar <mingo@elte.hu> wrote:

> Note: Andrew might get grumpy when 
> your PCI tree starts changing nearby places in arch/x86/pci again and it 
> clashes with these changes in x86.git

s/Andrew/Stephen/I hope/;)/

Hopefully we can soon start feeding these more problematic trees into linux-next
and yes, Stephen will need some more thought/support from his upstreams to make
that viable.

Re: [PATCH 0/8] AMD opteron mm config numa etc

[Ingo Molnar]

* Andrew Morton <akpm@linux-foundation.org> wrote:

> On Wed, 20 Feb 2008 07:37:52 +0100 Ingo Molnar <mingo@elte.hu> wrote:
> 
> > Note: Andrew might get grumpy when 
> > your PCI tree starts changing nearby places in arch/x86/pci again and it 
> > clashes with these changes in x86.git
> 
> s/Andrew/Stephen/I hope/;)/
> 
> Hopefully we can soon start feeding these more problematic trees into 
> linux-next and yes, Stephen will need some more thought/support from 
> his upstreams to make that viable.

btw., the correct metric would be "real user-side regressions per 
commit" (maybe real regressions per line of code changed), not "number 
of commits". With the latter metric, x86.git is "problematic". For the 
former, it's much less so ;-)

i.e. you should punish buggy trees that affect real testers out there, 
not high-flux trees that by virtue of their flux cause more integration 
work.

	Ingo