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
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
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
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
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
> 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.
> > > >
> > > >
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
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
> 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
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
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;
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?
> > >
> >
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
* 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
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
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.
>
> > 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
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
> >
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
>
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
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
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 currently. I
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.
All the
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 which can have
* 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 to? (The NMI
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?
But a node is just
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 they are even
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 normally?) but
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 given the
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
me to
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 conceived as a
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 third
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
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 defined by its memory?
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 defined by its memory?
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 machines.
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 future.
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
38 matches
Mail list logo
