Re: x86 patches was Re: -mm merge plans for 2.6.24

2007-10-02 Thread Christoph Lameter
On Tue, 2 Oct 2007, KAMEZAWA Hiroyuki wrote: > For fujitsu, problem is called "empty" node. Future SGI platforms (actually also current one can have but nothing like that is deployed to my knowledge) have nodes with only cpus. Current SGI platforms have nodes with just I/O that we so far cannot

Re: x86 patches was Re: -mm merge plans for 2.6.24

2007-10-02 Thread Christoph Lameter
On Tue, 2 Oct 2007, KAMEZAWA Hiroyuki wrote: > > There was a real-world need for this, I think from the Fujitsu guys. That > > should be spelled out in the changelog but isn't. > > Yes, Fujitsu and HP guys really need this memory-less-node support. The SGI guys also need this support in the fu

Re: x86 patches was Re: -mm merge plans for 2.6.24

2007-10-02 Thread Lee Schermerhorn
On Tue, 2007-10-02 at 00:43 -0700, Andrew Morton wrote: > On Tue, 2 Oct 2007 16:36:24 +0900 KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote: > > > On Tue, 2 Oct 2007 00:18:09 -0700 > > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > > > > > How come? Memoryless node can and do occur in real-world

Re: x86 patches was Re: -mm merge plans for 2.6.24

2007-10-02 Thread Lee Schermerhorn
On Tue, 2007-10-02 at 16:36 +0900, KAMEZAWA Hiroyuki wrote: > On Tue, 2 Oct 2007 00:18:09 -0700 > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > > > How come? Memoryless node can and do occur in real-world machines. > > > > Kernel > > > > should support that? > > > > > > But a node is just

Re: x86 patches was Re: -mm merge plans for 2.6.24

2007-10-02 Thread Nish Aravamudan
On 10/2/07, KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote: > On Tue, 2 Oct 2007 00:18:09 -0700 > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > > > How come? Memoryless node can and do occur in real-world machines. > > > > Kernel > > > > should support that? > > > > > > But a node is just defi

Re: x86 patches was Re: -mm merge plans for 2.6.24

2007-10-02 Thread Yasunori Goto
> On Tue, 2 Oct 2007 00:43:24 -0700 > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > On Tue, 2 Oct 2007 16:36:24 +0900 KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> > > > > Don't think so. A node is a lump of circuitry which can have zero or > > > > more > > > > CPUs, IO and memory. > > > > > > > > It

Re: x86 patches was Re: -mm merge plans for 2.6.24

2007-10-02 Thread Andy Whitcroft
On Tue, Oct 02, 2007 at 09:01:10AM +0200, Andi Kleen wrote: > x86_64-sparsemem_vmemmap-2m-page-size-support.patch > x86_64-sparsemem_vmemmap-vmemmap-x86_64-convert-to-new-helper-based-initialisation.patch > > Look like these two should be merged together > > Also I'm concerned about a t

Re: x86 patches was Re: -mm merge plans for 2.6.24

2007-10-02 Thread KAMEZAWA Hiroyuki
On Tue, 2 Oct 2007 00:43:24 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > On Tue, 2 Oct 2007 16:36:24 +0900 KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> > > > Don't think so. A node is a lump of circuitry which can have zero or more > > > CPUs, IO and memory. > > > > > > It may initially have been

Re: x86 patches was Re: -mm merge plans for 2.6.24

2007-10-02 Thread Andi Kleen
> Grumble. The options are: > > a) export it in the kernel's native size and have userspace figure it > out > b) add a header > c) lie to 32-bit apps on 64-bit kernels > d) always export 32 bits > e) always export 64 bits > > I started with (a), switched to (b), and then Alan and Dave convinced >

Re: x86 patches was Re: -mm merge plans for 2.6.24

2007-10-02 Thread Matt Mackall
On Tue, Oct 02, 2007 at 12:18:09AM -0700, Andrew Morton wrote: > > > If so, that might be OK - the app just needs a reliable way of working out > > > whether it's on a 32- or 64-bit kernel? > > > > That would be ugly and a little error prone (would this case really be > > tested in user space nor

Re: x86 patches was Re: -mm merge plans for 2.6.24

2007-10-02 Thread Thomas Gleixner
On Tue, 2 Oct 2007, Andi Kleen wrote: > On Tue, Oct 02, 2007 at 09:37:03AM +0200, Ingo Molnar wrote: > > > > * Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > On 02 Oct 2007 08:18:17 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote: > > > > > > > The clockevents patches are not included in this; but

Re: x86 patches was Re: -mm merge plans for 2.6.24

2007-10-02 Thread Andrew Morton
On Tue, 2 Oct 2007 16:36:24 +0900 KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote: > On Tue, 2 Oct 2007 00:18:09 -0700 > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > > > How come? Memoryless node can and do occur in real-world machines. > > > > Kernel > > > > should support that? > > > > >

Re: x86 patches was Re: -mm merge plans for 2.6.24

2007-10-02 Thread Andi Kleen
On Tue, Oct 02, 2007 at 09:37:03AM +0200, Ingo Molnar wrote: > > * Andrew Morton <[EMAIL PROTECTED]> wrote: > > > On 02 Oct 2007 08:18:17 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote: > > > > > The clockevents patches are not included in this; but given the > > > recent trouble i'm not 100% sure t

Re: x86 patches was Re: -mm merge plans for 2.6.24

2007-10-02 Thread Ingo Molnar
* Andrew Morton <[EMAIL PROTECTED]> wrote: > On 02 Oct 2007 08:18:17 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote: > > > The clockevents patches are not included in this; but given the > > recent trouble i'm not 100% sure they are even ready yet. i'm curious, which "recent trouble" do you refer t

Re: x86 patches was Re: -mm merge plans for 2.6.24

2007-10-02 Thread KAMEZAWA Hiroyuki
On Tue, 2 Oct 2007 00:18:09 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > How come? Memoryless node can and do occur in real-world machines. > > > Kernel > > > should support that? > > > > But a node is just defined by its memory? > > Don't think so. A node is a lump of circuitry

Re: x86 patches was Re: -mm merge plans for 2.6.24

2007-10-02 Thread Andrew Morton
On Tue, 2 Oct 2007 09:01:10 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote: > > > These are fine to me, but should not all go through my tree > > > because most changes are in other architectures. > > > > I assume you're referring to just > > convert-cpu_sibling_map-to-be-a-per-cpu-variable* here. >

Re: x86 patches was Re: -mm merge plans for 2.6.24

2007-10-02 Thread Andi Kleen
> > These are fine to me, but should not all go through my tree > > because most changes are in other architectures. > > I assume you're referring to just > convert-cpu_sibling_map-to-be-a-per-cpu-variable* here. All the *-to-*per-cpu* patches from Mike yes > > > I have nothing pending currentl

Re: x86 patches was Re: -mm merge plans for 2.6.24

2007-10-01 Thread Andrew Morton
On 02 Oct 2007 08:18:17 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote: > Andrew Morton <[EMAIL PROTECTED]> writes: > > > > revert-x86_64-mm-cpa-einval.patch > > fix-x86_64-mm-sched-clock-share.patch > > agp-fix-race-condition-between-unmapping-and-freeing-pages.patch > > x86_64-mce-poll-at-idle_star

x86 patches was Re: -mm merge plans for 2.6.24

2007-10-01 Thread Andi Kleen
Andrew Morton <[EMAIL PROTECTED]> writes: > > revert-x86_64-mm-cpa-einval.patch > fix-x86_64-mm-sched-clock-share.patch > agp-fix-race-condition-between-unmapping-and-freeing-pages.patch > x86_64-mce-poll-at-idle_start-and-printk-fix.patch > fix-x86_64-mm-unwinder.patch > geode-mfgpt-support-for-g