Lee wrote:
> Also, your cpuset/mempolicy work will probably need to undo the
> unconditional masking in contextualize_policy() and/or save the original
> node mask somewhere...
Yeah, something like that ... just a small matter of code.
--
I won't rest till it's the best ...
On Tue, 5 Feb 2008, Lee Schermerhorn wrote:
> The patch I just posted doesn't depend on the numactl changes and seems
> quite minimal to me. I think it cleans up the differences between
> set_mempolicy() and mbind(), as well. However, some may take exception
> to the change in
On Tue, 2008-02-05 at 15:33 -0600, Paul Jackson wrote:
> David wrote:
> > It would be disappointing to see a lot of work done to fix
>
> The suggested patch of KOSAKI Motohiro didn't look like a lot of work to me.
>
> I continue to prefer not to hijack this thread for that other discussion.
>
David wrote:
> It would be disappointing to see a lot of work done to fix
The suggested patch of KOSAKI Motohiro didn't look like a lot of work to me.
I continue to prefer not to hijack this thread for that other discussion.
Just presenting your position and calling it "simple" is misleading.
On Tue, 5 Feb 2008, Paul Jackson wrote:
> David wrote:
> > The more alarming result of these remaps is in the MPOL_BIND case, as
> > we've talked about before. The language in set_mempolicy(2):
>
> You're diving into the middle of a rather involved discussion
> we had on the other various
David wrote:
> The more alarming result of these remaps is in the MPOL_BIND case, as
> we've talked about before. The language in set_mempolicy(2):
You're diving into the middle of a rather involved discussion
we had on the other various patches proposed to extend the
interaction of mempolicy's
On Tue, 5 Feb 2008, Paul Jackson wrote:
> Since any of those future patches only add optional modes
> with new flags, while preserving current behaviour if you
> don't use one of the new flags, therefore the current behavior
> has to work as best it can.
>
There's a subtlety to this issue that
On Tue, 5 Feb 2008, Paul Jackson wrote:
> But that discussion touched on some other long standing deficiencies
> in the way that I had originally glued cpusets and memory policies
> together. The current mechanism doesn't handle changing cpusets very
> well, especially if the number of nodes in
Christoph wrote:
> Can we fix up his patch to address the immediate issue?
Since any of those future patches only add optional modes
with new flags, while preserving current behaviour if you
don't use one of the new flags, therefore the current behavior
has to work as best it can.
Therefore
On Tue, 5 Feb 2008, Lee Schermerhorn wrote:
> Christoph: you are free to ignore any part of this discussion that you
> wish...
Had the impression that we are ignoring Kosaki's fix to the problem. Can
we fix up his patch to address the immediate issue?
--
To unsubscribe from this list: send
On Tue, 2008-02-05 at 10:12 -0800, Christoph Lameter wrote:
> Could we focus on the problem instead of discussion of new patches under
> development?
Christoph: you are free to ignore any part of this discussion that you
wish...
> Can we confirm that what Kosaki sees is a bug?
by definition,
Could we focus on the problem instead of discussion of new patches under
development? Can we confirm that what Kosaki sees is a bug?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Tue, 2008-02-05 at 14:31 +, Mel Gorman wrote:
> On (04/02/08 13:20), Lee Schermerhorn didst pronounce:
> > > > When the kernel behaviour changes and breaks user space then the kernel
> > > > is usually wrong. Cc'ed Lee S. who maintains the kernel code now.
> >
> > The memoryless nodes
On (04/02/08 13:20), Lee Schermerhorn didst pronounce:
> > > When the kernel behaviour changes and breaks user space then the kernel
> > > is usually wrong. Cc'ed Lee S. who maintains the kernel code now.
>
> The memoryless nodes patch series changed a lot of things, so just
> reverting this one
Hi Paul
> Hopefully this week or next, I will publish this patch proposal.
Great.
at that time, I will join review the patch with presure :)
- kosaki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Lee wrote:
> I don't know the current state of Paul's rework of cpusets and
> mems_allowed. That probably resolves this issue, if he still plans on
> allowing a fully populated mask to indicate interleaving over all
> allowed nodes.
It got a bit stalled out for the last month (my employer had
Lee wrote:
I don't know the current state of Paul's rework of cpusets and
mems_allowed. That probably resolves this issue, if he still plans on
allowing a fully populated mask to indicate interleaving over all
allowed nodes.
It got a bit stalled out for the last month (my employer had other
Hi Paul
Hopefully this week or next, I will publish this patch proposal.
Great.
at that time, I will join review the patch with presure :)
- kosaki
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Tue, 2008-02-05 at 14:31 +, Mel Gorman wrote:
On (04/02/08 13:20), Lee Schermerhorn didst pronounce:
When the kernel behaviour changes and breaks user space then the kernel
is usually wrong. Cc'ed Lee S. who maintains the kernel code now.
The memoryless nodes patch series
On (04/02/08 13:20), Lee Schermerhorn didst pronounce:
When the kernel behaviour changes and breaks user space then the kernel
is usually wrong. Cc'ed Lee S. who maintains the kernel code now.
The memoryless nodes patch series changed a lot of things, so just
reverting this one area
Could we focus on the problem instead of discussion of new patches under
development? Can we confirm that what Kosaki sees is a bug?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Tue, 2008-02-05 at 10:12 -0800, Christoph Lameter wrote:
Could we focus on the problem instead of discussion of new patches under
development?
Christoph: you are free to ignore any part of this discussion that you
wish...
Can we confirm that what Kosaki sees is a bug?
by definition,
On Tue, 5 Feb 2008, Lee Schermerhorn wrote:
Christoph: you are free to ignore any part of this discussion that you
wish...
Had the impression that we are ignoring Kosaki's fix to the problem. Can
we fix up his patch to address the immediate issue?
--
To unsubscribe from this list: send the
Christoph wrote:
Can we fix up his patch to address the immediate issue?
Since any of those future patches only add optional modes
with new flags, while preserving current behaviour if you
don't use one of the new flags, therefore the current behavior
has to work as best it can.
Therefore fixes
On Tue, 5 Feb 2008, Paul Jackson wrote:
But that discussion touched on some other long standing deficiencies
in the way that I had originally glued cpusets and memory policies
together. The current mechanism doesn't handle changing cpusets very
well, especially if the number of nodes in the
On Tue, 5 Feb 2008, Paul Jackson wrote:
Since any of those future patches only add optional modes
with new flags, while preserving current behaviour if you
don't use one of the new flags, therefore the current behavior
has to work as best it can.
There's a subtlety to this issue that
David wrote:
The more alarming result of these remaps is in the MPOL_BIND case, as
we've talked about before. The language in set_mempolicy(2):
You're diving into the middle of a rather involved discussion
we had on the other various patches proposed to extend the
interaction of mempolicy's
On Tue, 5 Feb 2008, Paul Jackson wrote:
David wrote:
The more alarming result of these remaps is in the MPOL_BIND case, as
we've talked about before. The language in set_mempolicy(2):
You're diving into the middle of a rather involved discussion
we had on the other various patches
David wrote:
It would be disappointing to see a lot of work done to fix
The suggested patch of KOSAKI Motohiro didn't look like a lot of work to me.
I continue to prefer not to hijack this thread for that other discussion.
Just presenting your position and calling it simple is misleading.
The
On Tue, 2008-02-05 at 15:33 -0600, Paul Jackson wrote:
David wrote:
It would be disappointing to see a lot of work done to fix
The suggested patch of KOSAKI Motohiro didn't look like a lot of work to me.
I continue to prefer not to hijack this thread for that other discussion.
Just
On Tue, 5 Feb 2008, Lee Schermerhorn wrote:
The patch I just posted doesn't depend on the numactl changes and seems
quite minimal to me. I think it cleans up the differences between
set_mempolicy() and mbind(), as well. However, some may take exception
to the change in behavior--silently
Lee wrote:
Also, your cpuset/mempolicy work will probably need to undo the
unconditional masking in contextualize_policy() and/or save the original
node mask somewhere...
Yeah, something like that ... just a small matter of code.
--
I won't rest till it's the best ...
On Sat, 2 Feb 2008, Andi Kleen wrote:
> To be honest I've never tried seriously to make 32bit NUMA policy
> (with highmem) work well; just kept it at a "should not break"
> level. That is because with highmem the kernel's choices at
> placing memory are seriously limited anyways so I doubt 32bit
On Sat, 2008-02-02 at 18:37 +0900, KOSAKI Motohiro wrote:
> Hi Andi,
>
> > > 3. 2.6.24-rc8-mm1 set_mempolicy(2) behavior
> > >3.1 check nodesubset(nodemask argument, node_states[N_HIGH_MEMORY])
> > >in mpol_check_policy()
> > >
> > > -> check failed when memmoryless node exist.
> >
On Sat, 2008-02-02 at 18:37 +0900, KOSAKI Motohiro wrote:
Hi Andi,
3. 2.6.24-rc8-mm1 set_mempolicy(2) behavior
3.1 check nodesubset(nodemask argument, node_states[N_HIGH_MEMORY])
in mpol_check_policy()
- check failed when memmoryless node exist.
(i.e.
On Sat, 2 Feb 2008, Andi Kleen wrote:
To be honest I've never tried seriously to make 32bit NUMA policy
(with highmem) work well; just kept it at a should not break
level. That is because with highmem the kernel's choices at
placing memory are seriously limited anyways so I doubt 32bit
NUMA
> I have 1 simple question.
> Why do libnuma generate bitpattern of all bit on instead
> check /sys/devices/system/node/has_high_memory nor
> check /sys/devices/system/node/online?
>
> Do you know it?
It's far simpler and cheaper (sysfs is expensive) to do this in the kernel
and besides the
Hi Andi,
> > 3. 2.6.24-rc8-mm1 set_mempolicy(2) behavior
> >3.1 check nodesubset(nodemask argument, node_states[N_HIGH_MEMORY])
> >in mpol_check_policy()
> >
> > -> check failed when memmoryless node exist.
> >(i.e. node_states[N_HIGH_MEMORY] of my machine is 0xc)
> >
[intentional full quote]
On Sat, Feb 02, 2008 at 05:12:30PM +0900, KOSAKI Motohiro wrote:
> I tested numactl on 2.6.24-rc8-mm1.
> and I found strange behavior.
>
> test method and result.
>
> $ numactl --interleave=all ls
> set_mempolicy: Invalid argument
> setting interleave
Hi
I tested numactl on 2.6.24-rc8-mm1.
and I found strange behavior.
test method and result.
$ numactl --interleave=all ls
set_mempolicy: Invalid argument
setting interleave mask: Invalid argument
numactl command download from
Hi
I tested numactl on 2.6.24-rc8-mm1.
and I found strange behavior.
test method and result.
$ numactl --interleave=all ls
set_mempolicy: Invalid argument
setting interleave mask: Invalid argument
numactl command download from
[intentional full quote]
On Sat, Feb 02, 2008 at 05:12:30PM +0900, KOSAKI Motohiro wrote:
I tested numactl on 2.6.24-rc8-mm1.
and I found strange behavior.
test method and result.
$ numactl --interleave=all ls
set_mempolicy: Invalid argument
setting interleave mask:
Hi Andi,
3. 2.6.24-rc8-mm1 set_mempolicy(2) behavior
3.1 check nodesubset(nodemask argument, node_states[N_HIGH_MEMORY])
in mpol_check_policy()
- check failed when memmoryless node exist.
(i.e. node_states[N_HIGH_MEMORY] of my machine is 0xc)
4. RHEL5.1
I have 1 simple question.
Why do libnuma generate bitpattern of all bit on instead
check /sys/devices/system/node/has_high_memory nor
check /sys/devices/system/node/online?
Do you know it?
It's far simpler and cheaper (sysfs is expensive) to do this in the kernel
and besides the kernel
44 matches
Mail list logo
