> Do you know when the patch that adds
> bitmap_onto(), which is a name I think I noticed you liking, will be
> available?
Thanks in good part to your various questions regarding it, I realized
a significant error in the central piece of code in that patch, the
routine
On Fri, 15 Feb 2008, Paul Jackson wrote:
> --- 2.6.24-mm1.orig/include/linux/mempolicy.h 2008-02-15 00:11:10.0
> -0800
> +++ 2.6.24-mm1/include/linux/mempolicy.h 2008-02-15 15:16:16.031031424
> -0800
> @@ -8,6 +8,14 @@
> * Copyright 2003,2004 Andi Kleen SuSE Labs
> */
>
> +/*
David responding to pj:
> > I don't think so. It's not possible to detemine if exactly the low
> > eight bits of the 'policy' short are a valid mode, -however- that
> > "eight" is a spurious detail. Remove it.
>
> Sure it is, you can determine if the low MPOL_FLAG_SHIFT bits are a valid
> mode
On Fri, 15 Feb 2008, David Rientjes wrote:
> It would be possible to do all of this in both sys_set_mempolicy() and
> sys_mbind() by masking off the set of possible modes and checking the
> result for being >= MPOL_MAX:
>
> if ((mode & MPOL_MODE_FLAGS) >= MPOL_MAX)
> return
On Fri, 15 Feb 2008, Paul Jackson wrote:
> I don't think so. It's not possible to detemine if exactly the low
> eight bits of the 'policy' short are a valid mode, -however- that
> "eight" is a spurious detail. Remove it.
>
Sure it is, you can determine if the low MPOL_FLAG_SHIFT bits are a
On Fri, 15 Feb 2008, Paul Jackson wrote:
> So that last line should be:
>
> > 1,3,5 4-105,7,9
>
What about this case where one of the relative nodes wraps around to
represent an already set node in the result?
relativemems_allowedresult
> So basically the "relative" nodemask that is passed with
> MPOL_F_RELATIVE_NODES is wrapped around the allowed nodes?
>
> relative nodemask mems_allowedresult
> 1,3,5 4 4
> 1,3,5 4-6 4-6
> 1,3,5
> like MPOL_F_RELATIVE_NODES or whatever Paul decides to call it
MPOL_F_RELATIVE_NODES it is.
I see no compelling need for this name to track whatever
we name the relative bitmap operator. They are related,
but not the same thing.
--
I won't rest till it's the best ...
David wrote:
> But without MPOL_FLAG_SHIFT it becomes
> impossible to determine whether a user passed an invalid flag.
I don't think so. It's not possible to detemine if exactly the low
eight bits of the 'policy' short are a valid mode, -however- that
"eight" is a spurious detail. Remove it.
David wrote:
But without MPOL_FLAG_SHIFT it becomes
impossible to determine whether a user passed an invalid flag.
I don't think so. It's not possible to detemine if exactly the low
eight bits of the 'policy' short are a valid mode, -however- that
eight is a spurious detail. Remove it.
like MPOL_F_RELATIVE_NODES or whatever Paul decides to call it
MPOL_F_RELATIVE_NODES it is.
I see no compelling need for this name to track whatever
we name the relative bitmap operator. They are related,
but not the same thing.
--
I won't rest till it's the best ...
So basically the relative nodemask that is passed with
MPOL_F_RELATIVE_NODES is wrapped around the allowed nodes?
relative nodemask mems_allowedresult
1,3,5 4 4
1,3,5 4-6 4-6
1,3,5
On Fri, 15 Feb 2008, David Rientjes wrote:
It would be possible to do all of this in both sys_set_mempolicy() and
sys_mbind() by masking off the set of possible modes and checking the
result for being = MPOL_MAX:
if ((mode MPOL_MODE_FLAGS) = MPOL_MAX)
return -EINVAL;
On Fri, 15 Feb 2008, Paul Jackson wrote:
So that last line should be:
1,3,5 4-105,7,9
What about this case where one of the relative nodes wraps around to
represent an already set node in the result?
relativemems_allowedresult
On Fri, 15 Feb 2008, Paul Jackson wrote:
I don't think so. It's not possible to detemine if exactly the low
eight bits of the 'policy' short are a valid mode, -however- that
eight is a spurious detail. Remove it.
Sure it is, you can determine if the low MPOL_FLAG_SHIFT bits are a valid
David responding to pj:
I don't think so. It's not possible to detemine if exactly the low
eight bits of the 'policy' short are a valid mode, -however- that
eight is a spurious detail. Remove it.
Sure it is, you can determine if the low MPOL_FLAG_SHIFT bits are a valid
mode by masking
On Fri, 15 Feb 2008, Paul Jackson wrote:
--- 2.6.24-mm1.orig/include/linux/mempolicy.h 2008-02-15 00:11:10.0
-0800
+++ 2.6.24-mm1/include/linux/mempolicy.h 2008-02-15 15:16:16.031031424
-0800
@@ -8,6 +8,14 @@
* Copyright 2003,2004 Andi Kleen SuSE Labs
*/
+/*
+ * The
Do you know when the patch that adds
bitmap_onto(), which is a name I think I noticed you liking, will be
available?
Thanks in good part to your various questions regarding it, I realized
a significant error in the central piece of code in that patch, the
routine lib/bitmap.c:bitmap_onto().
On Thu, 14 Feb 2008, David Rientjes wrote:
> We'll need to decide whether mpol_equal() is determining the equality of
> the currently effected mempolicy (whereas policy->user_nodemask is
> irrelevant) or the whole intended mempolicy overall.
>
I've done the latter in the latest patchset.
On Thu, 14 Feb 2008, Paul Jackson wrote:
> In mempolicy.h, the lines:
>
> /*
> * The lower MPOL_FLAG_SHIFT bits of the policy mode represent the MPOL_*
> * constants defined in enum mempolicy_mode. The upper bits represent
> * optional set_mempolicy() MPOL_F_* mode flags.
>
On Thu, 14 Feb 2008, Paul Jackson wrote:
> No and yes. The manner in which too many nodes (as requested in a
> RELATIVE mask) are folded into too small a cpuset is not actually
> that critical, so long as it doesn't come up empty. However, what
> I'll be recommending, in a follow-up patch, will
On Thu, 14 Feb 2008, Paul Jackson wrote:
> If we ever call mpol_rebind_policy() with an
> MPOL_PREFERRED|MPOL_F_STATIC_NODES
> policy when the preferred_node doesn't happen to be in the current cpuset,
> then would the following lines loose the preferred node setting, such that
> it didn't get
I had taken a vow of silence on this one, but couldn't resist one more
round.
David wrote:
> My preference (both mode and flags stored in the same member of struct
> mempolicy):
>
>Advantages:
>
> - completely consistent with the userspace API of passing modes
> and flags
David wrote:
> So let's say, like my first example from the previous email, that you have
> MPOL_INTERLEAVE | MPOL_F_RELATIVE_NODES over nodes 3-4 and your cpuset's
> mems is only nodes 5-7. This would interleave over no nodes. Correct?
Given what I said yesterday, that would be a correct
Paul, responding (incorrectly) to David:
> > So, for example, if the task is bound by mems 1-3, and it asks for
> > MPOL_INTERLEAVE over 2-4, then initially the mempolicy is only effected
> > over node 3 and if it's later expanded to mems 1-8, then the mempolicy is
> > effected over nodes 3-5,
A few more review comments on details of this patch set ...
=
In mempolicy.h, the lines:
/*
* The lower MPOL_FLAG_SHIFT bits of the policy mode represent the MPOL_*
* constants defined in enum mempolicy_mode. The upper bits represent
* optional set_mempolicy()
A few more review comments on details of this patch set ...
=
In mempolicy.h, the lines:
/*
* The lower MPOL_FLAG_SHIFT bits of the policy mode represent the MPOL_*
* constants defined in enum mempolicy_mode. The upper bits represent
* optional set_mempolicy()
Paul, responding (incorrectly) to David:
So, for example, if the task is bound by mems 1-3, and it asks for
MPOL_INTERLEAVE over 2-4, then initially the mempolicy is only effected
over node 3 and if it's later expanded to mems 1-8, then the mempolicy is
effected over nodes 3-5, right?
David wrote:
So let's say, like my first example from the previous email, that you have
MPOL_INTERLEAVE | MPOL_F_RELATIVE_NODES over nodes 3-4 and your cpuset's
mems is only nodes 5-7. This would interleave over no nodes. Correct?
Given what I said yesterday, that would be a correct
I had taken a vow of silence on this one, but couldn't resist one more
round.
David wrote:
My preference (both mode and flags stored in the same member of struct
mempolicy):
Advantages:
- completely consistent with the userspace API of passing modes
and flags together
On Thu, 14 Feb 2008, Paul Jackson wrote:
If we ever call mpol_rebind_policy() with an
MPOL_PREFERRED|MPOL_F_STATIC_NODES
policy when the preferred_node doesn't happen to be in the current cpuset,
then would the following lines loose the preferred node setting, such that
it didn't get
On Thu, 14 Feb 2008, Paul Jackson wrote:
In mempolicy.h, the lines:
/*
* The lower MPOL_FLAG_SHIFT bits of the policy mode represent the MPOL_*
* constants defined in enum mempolicy_mode. The upper bits represent
* optional set_mempolicy() MPOL_F_* mode flags.
*/
On Thu, 14 Feb 2008, David Rientjes wrote:
We'll need to decide whether mpol_equal() is determining the equality of
the currently effected mempolicy (whereas policy-user_nodemask is
irrelevant) or the whole intended mempolicy overall.
I've done the latter in the latest patchset.
Since
On Wed, 13 Feb 2008, Paul Jackson wrote:
> Yes, if an application considers nodes to be interchangeable, I'm
> trying to avoid having that application -have- to know its current
> cpuset placement, for two reasons:
>
> For one thing, it's racey. It's cpuset placement could change,
>
David wrote:
> You're specifically trying to avoid having the application know about its
> cpuset placement with regard to mems at the time it sets up its mempolicy,
> right? Otherwise it could already setup this relative nodemask by
> selecting node 2, from your example above, in its
On Wed, 13 Feb 2008, Lee Schermerhorn wrote:
> > Yeah, it gets tricky. I'm not too sure about only pulling the mode and
> > flags apart at mpol_new() time because perhaps, in the future, there will
> > be flag and mode combinations that are only applicable for set_mempolicy()
> > and not for
On Wed, 13 Feb 2008, Lee Schermerhorn wrote:
> > > If we just want to preserve existing behavior, we can define an
> > > additional mode flag that we set in the sbinfo policy in
> > > shmem_parse_mpol() and test in mpol_new(). If we want to be able to
> > > specify existing or new behavior, we
On Wed, 2008-02-13 at 10:48 -0800, David Rientjes wrote:
> On Wed, 13 Feb 2008, Lee Schermerhorn wrote:
>
> > > > 2) Those 'mpol_mode()' wrappers on all those mempolicy->policy
> > > > evaluations look dangerous to me. It looks like a code bug
> > > > waiting to happen. Unless I miss
On Wed, 13 Feb 2008, Paul Jackson wrote:
> No -- MPOL_F_STATIC_NODES does not handle my second case. Notice the
> phrase 'cpuset relative.'
>
> In my second case, nodes are numbered relative to the cpuset. If you
> say "node 2" then you mean whatever is the third (since numbering is
> zero
David wrote:
> Yeah, it gets tricky.
If you can stand to read my code, look at that big patch I sent you
and Lee, dated "Sun, 23 Dec 2007 22:24:02 -0600", under the Subject
of "Re: [RFC] cpuset relative memory policies - second choice",
where I did this, keeping the 'policy' field unchanged in
On Wed, 13 Feb 2008, Lee Schermerhorn wrote:
> > > 2) Those 'mpol_mode()' wrappers on all those mempolicy->policy
> > > evaluations look dangerous to me. It looks like a code bug
> > > waiting to happen. Unless I miss my guess, if you forget one of
> > > those wrappers (or someone
David, responding to pj, write:
> > 2) a cpuset relative mode that correctly handled the case of cpusets
> > growing larger (increased numbers of nodes.)
> >
> > I'd like to persuade you to add case (2) as well. But I suspect,
> > given that case (2) was never as compelling to you as it was
On Tue, 2008-02-12 at 20:18 -0800, David Rientjes wrote:
> On Tue, 12 Feb 2008, Lee Schermerhorn wrote:
>
> > > Adds another member to struct mempolicy,
> > >
> > > nodemask_t user_nodemask
> > >
> > > that stores the the nodemask that the user passed when he or she created
> > > the
On Wed, 2008-02-13 at 01:36 -0800, David Rientjes wrote:
> On Wed, 13 Feb 2008, Paul Jackson wrote:
>
> > The infamous unpublished (except to a few) patch I drafted on Christmas
> > (Dec 25, 2007) basically added two new modes for how mempolicy
> > nodemasks were to be resolved:
> > 1) a static,
On Tue, 2008-02-12 at 21:06 -0800, David Rientjes wrote:
> On Tue, 12 Feb 2008, David Rientjes wrote:
>
> > Since we're allowed to remap the node to a different node than the user
> > specified with either syscall, the current behavior is that "one node is
> > as good as another." In other
On Wed, 13 Feb 2008, Paul Jackson wrote:
> The infamous unpublished (except to a few) patch I drafted on Christmas
> (Dec 25, 2007) basically added two new modes for how mempolicy
> nodemasks were to be resolved:
> 1) a static, no remap, mode, such as in this present patchset, and
> 2) a cpuset
Ok ... I read this patchset a little closer, and see a couple
of items worth noting.
The infamous unpublished (except to a few) patch I drafted on Christmas
(Dec 25, 2007) basically added two new modes for how mempolicy
nodemasks were to be resolved:
1) a static, no remap, mode, such as in this
Ok ... I read this patchset a little closer, and see a couple
of items worth noting.
The infamous unpublished (except to a few) patch I drafted on Christmas
(Dec 25, 2007) basically added two new modes for how mempolicy
nodemasks were to be resolved:
1) a static, no remap, mode, such as in this
On Wed, 13 Feb 2008, Paul Jackson wrote:
The infamous unpublished (except to a few) patch I drafted on Christmas
(Dec 25, 2007) basically added two new modes for how mempolicy
nodemasks were to be resolved:
1) a static, no remap, mode, such as in this present patchset, and
2) a cpuset
On Tue, 2008-02-12 at 20:18 -0800, David Rientjes wrote:
On Tue, 12 Feb 2008, Lee Schermerhorn wrote:
Adds another member to struct mempolicy,
nodemask_t user_nodemask
that stores the the nodemask that the user passed when he or she created
the mempolicy via
On Wed, 2008-02-13 at 01:36 -0800, David Rientjes wrote:
On Wed, 13 Feb 2008, Paul Jackson wrote:
The infamous unpublished (except to a few) patch I drafted on Christmas
(Dec 25, 2007) basically added two new modes for how mempolicy
nodemasks were to be resolved:
1) a static, no remap,
David, responding to pj, write:
2) a cpuset relative mode that correctly handled the case of cpusets
growing larger (increased numbers of nodes.)
I'd like to persuade you to add case (2) as well. But I suspect,
given that case (2) was never as compelling to you as it was to me
David wrote:
Yeah, it gets tricky.
If you can stand to read my code, look at that big patch I sent you
and Lee, dated Sun, 23 Dec 2007 22:24:02 -0600, under the Subject
of Re: [RFC] cpuset relative memory policies - second choice,
where I did this, keeping the 'policy' field unchanged in struct
On Wed, 13 Feb 2008, Lee Schermerhorn wrote:
2) Those 'mpol_mode()' wrappers on all those mempolicy-policy
evaluations look dangerous to me. It looks like a code bug
waiting to happen. Unless I miss my guess, if you forget one of
those wrappers (or someone making a
On Wed, 13 Feb 2008, Lee Schermerhorn wrote:
If we just want to preserve existing behavior, we can define an
additional mode flag that we set in the sbinfo policy in
shmem_parse_mpol() and test in mpol_new(). If we want to be able to
specify existing or new behavior, we can use the
On Wed, 2008-02-13 at 10:48 -0800, David Rientjes wrote:
On Wed, 13 Feb 2008, Lee Schermerhorn wrote:
2) Those 'mpol_mode()' wrappers on all those mempolicy-policy
evaluations look dangerous to me. It looks like a code bug
waiting to happen. Unless I miss my guess, if you
On Wed, 13 Feb 2008, Paul Jackson wrote:
No -- MPOL_F_STATIC_NODES does not handle my second case. Notice the
phrase 'cpuset relative.'
In my second case, nodes are numbered relative to the cpuset. If you
say node 2 then you mean whatever is the third (since numbering is
zero based) node
On Wed, 13 Feb 2008, Lee Schermerhorn wrote:
Yeah, it gets tricky. I'm not too sure about only pulling the mode and
flags apart at mpol_new() time because perhaps, in the future, there will
be flag and mode combinations that are only applicable for set_mempolicy()
and not for mbind(),
David wrote:
You're specifically trying to avoid having the application know about its
cpuset placement with regard to mems at the time it sets up its mempolicy,
right? Otherwise it could already setup this relative nodemask by
selecting node 2, from your example above, in its mems_allowed
On Wed, 13 Feb 2008, Paul Jackson wrote:
Yes, if an application considers nodes to be interchangeable, I'm
trying to avoid having that application -have- to know its current
cpuset placement, for two reasons:
For one thing, it's racey. It's cpuset placement could change,
On Tue, 12 Feb 2008, David Rientjes wrote:
> Since we're allowed to remap the node to a different node than the user
> specified with either syscall, the current behavior is that "one node is
> as good as another." In other words, we're trying to accomodate the mode
> first by setting
On Tue, 12 Feb 2008, Paul Jackson wrote:
> > I've redone my patchset based on the feedback that I've received
>
> Will you be sending that along soon? I was just getting into my
> review of this patchset, and I suppose it would be better to
> review the latest and greatest.
>
Lee had some
On Tue, 12 Feb 2008, Lee Schermerhorn wrote:
> > Adds another member to struct mempolicy,
> >
> > nodemask_t user_nodemask
> >
> > that stores the the nodemask that the user passed when he or she created
> > the mempolicy via set_mempolicy() or mbind(). When using
> > MPOL_F_STATIC_NODES,
David wrote:
> I've redone my patchset based on the feedback that I've received
Will you be sending that along soon? I was just getting into my
review of this patchset, and I suppose it would be better to
review the latest and greatest.
--
I won't rest till it's the best ...
On Tue, 12 Feb 2008, Paul Jackson wrote:
> > 1) we've discussed the issue of returning EINVAL for non-empty nodemasks
> > with MPOL_DEFAULT. By removing this restriction, we run the risk of
> > breaking applications if we should ever want to define a semantic to
> > non-empty node mask for
Lee wrote:
> 1) we've discussed the issue of returning EINVAL for non-empty nodemasks
> with MPOL_DEFAULT. By removing this restriction, we run the risk of
> breaking applications if we should ever want to define a semantic to
> non-empty node mask for MPOL_DEFAULT.
The bigger risk, in my view,
On Tue, 12 Feb 2008, Lee Schermerhorn wrote:
> PATCH mempolicy - consolidate mpol_new() error paths
>
> Use common error path in mpol_new() for errors that we discover
> after allocation the new mempolicy structure. Free the mempolicy
> in the common error path.
>
> Signed-off-by: Lee
On Mon, 2008-02-11 at 11:56 -0800, David Rientjes wrote:
> On Tue, 12 Feb 2008, KOSAKI Motohiro wrote:
>
> > > @@ -218,21 +167,27 @@ static struct mempolicy *mpol_new(enum
> > > mempolicy_mode mode,
> > > return ERR_PTR(-ENOMEM);
> > > flags &= MPOL_MODE_FLAGS;
> > >
On Mon, 2008-02-11 at 07:30 -0800, David Rientjes wrote:
> Add an optional mempolicy mode flag, MPOL_F_STATIC_NODES, that suppresses
> the node remap when the policy is rebound.
>
> Adds another member to struct mempolicy,
>
> nodemask_t user_nodemask
>
> that stores the the nodemask
On Mon, 2008-02-11 at 11:56 -0800, David Rientjes wrote:
On Tue, 12 Feb 2008, KOSAKI Motohiro wrote:
@@ -218,21 +167,27 @@ static struct mempolicy *mpol_new(enum
mempolicy_mode mode,
return ERR_PTR(-ENOMEM);
flags = MPOL_MODE_FLAGS;
On Mon, 2008-02-11 at 07:30 -0800, David Rientjes wrote:
Add an optional mempolicy mode flag, MPOL_F_STATIC_NODES, that suppresses
the node remap when the policy is rebound.
Adds another member to struct mempolicy,
nodemask_t user_nodemask
that stores the the nodemask that the
On Tue, 12 Feb 2008, Paul Jackson wrote:
I've redone my patchset based on the feedback that I've received
Will you be sending that along soon? I was just getting into my
review of this patchset, and I suppose it would be better to
review the latest and greatest.
Lee had some questions
On Tue, 12 Feb 2008, Lee Schermerhorn wrote:
Adds another member to struct mempolicy,
nodemask_t user_nodemask
that stores the the nodemask that the user passed when he or she created
the mempolicy via set_mempolicy() or mbind(). When using
MPOL_F_STATIC_NODES, which is
On Tue, 12 Feb 2008, David Rientjes wrote:
Since we're allowed to remap the node to a different node than the user
specified with either syscall, the current behavior is that one node is
as good as another. In other words, we're trying to accomodate the mode
first by setting
David wrote:
I've redone my patchset based on the feedback that I've received
Will you be sending that along soon? I was just getting into my
review of this patchset, and I suppose it would be better to
review the latest and greatest.
--
I won't rest till it's the best ...
On Tue, 12 Feb 2008, Paul Jackson wrote:
1) we've discussed the issue of returning EINVAL for non-empty nodemasks
with MPOL_DEFAULT. By removing this restriction, we run the risk of
breaking applications if we should ever want to define a semantic to
non-empty node mask for MPOL_DEFAULT.
On Tue, 12 Feb 2008, Lee Schermerhorn wrote:
PATCH mempolicy - consolidate mpol_new() error paths
Use common error path in mpol_new() for errors that we discover
after allocation the new mempolicy structure. Free the mempolicy
in the common error path.
Signed-off-by: Lee Schermerhorn
Lee wrote:
1) we've discussed the issue of returning EINVAL for non-empty nodemasks
with MPOL_DEFAULT. By removing this restriction, we run the risk of
breaking applications if we should ever want to define a semantic to
non-empty node mask for MPOL_DEFAULT.
The bigger risk, in my view, is
On Tue, 12 Feb 2008, KOSAKI Motohiro wrote:
> > @@ -218,21 +167,27 @@ static struct mempolicy *mpol_new(enum mempolicy_mode
> > mode,
> > return ERR_PTR(-ENOMEM);
> > flags &= MPOL_MODE_FLAGS;
> > atomic_set(>refcnt, 1);
> > +
Looks conceptually good (I have not looked at the details).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi David,
In general, I like this feature.
and I found no bug in patch [1/4] and [2/4].
> @@ -218,21 +167,27 @@ static struct mempolicy *mpol_new(enum mempolicy_mode
> mode,
> return ERR_PTR(-ENOMEM);
> flags &= MPOL_MODE_FLAGS;
> atomic_set(>refcnt, 1);
> +
On Tue, 12 Feb 2008, KOSAKI Motohiro wrote:
@@ -218,21 +167,27 @@ static struct mempolicy *mpol_new(enum mempolicy_mode
mode,
return ERR_PTR(-ENOMEM);
flags = MPOL_MODE_FLAGS;
atomic_set(policy-refcnt, 1);
+ cpuset_update_task_memory_state();
+
Looks conceptually good (I have not looked at the details).
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi David,
In general, I like this feature.
and I found no bug in patch [1/4] and [2/4].
@@ -218,21 +167,27 @@ static struct mempolicy *mpol_new(enum mempolicy_mode
mode,
return ERR_PTR(-ENOMEM);
flags = MPOL_MODE_FLAGS;
atomic_set(policy-refcnt, 1);
+
84 matches
Mail list logo
