On Tue, 12 Feb 2008, Lee Schermerhorn wrote:
> What is the benefit of pulling the flags and mode apart at the user
> interface, passing them as separate args to mpol_new(), do_* and
> mpol_shared_policy_init() and then stitching them back together in
> mpol_new()? Modes passed in via
On Mon, 2008-02-11 at 07:30 -0800, David Rientjes wrote:
> With the evolution of mempolicies, it is necessary to support mempolicy
> mode flags that specify how the policy shall behave in certain
> circumstances. The most immediate need for mode flag support is to
> suppress remapping the
On Tue, 12 Feb 2008, Lee Schermerhorn wrote:
> Hmmm, so 'static' means "don't contexutalize"--i.e., don't mask off
> disallowed or memoryless nodes? That means we'll need to skip them in
> the interleave node calculation in the allocation path. Perhaps your
> patch already addresses this, but I
On Mon, 2008-02-11 at 11:34 -0800, David Rientjes wrote:
> On Mon, 11 Feb 2008, Lee Schermerhorn wrote:
>
> > These patches look good--well, interesting, anyway. I'm "off on
> > assignment" this week, so I won't get to review in detail, merge and
> > test them until next...
> >
>
> If, by
On Tue, 12 Feb 2008, Lee Schermerhorn wrote:
What is the benefit of pulling the flags and mode apart at the user
interface, passing them as separate args to mpol_new(), do_* and
mpol_shared_policy_init() and then stitching them back together in
mpol_new()? Modes passed in via
On Tue, 12 Feb 2008, Lee Schermerhorn wrote:
Hmmm, so 'static' means don't contexutalize--i.e., don't mask off
disallowed or memoryless nodes? That means we'll need to skip them in
the interleave node calculation in the allocation path. Perhaps your
patch already addresses this, but I
On Mon, 2008-02-11 at 07:30 -0800, David Rientjes wrote:
With the evolution of mempolicies, it is necessary to support mempolicy
mode flags that specify how the policy shall behave in certain
circumstances. The most immediate need for mode flag support is to
suppress remapping the nodemask
On Mon, 2008-02-11 at 11:34 -0800, David Rientjes wrote:
On Mon, 11 Feb 2008, Lee Schermerhorn wrote:
These patches look good--well, interesting, anyway. I'm off on
assignment this week, so I won't get to review in detail, merge and
test them until next...
If, by interesting,
David wrote:
> With my patchset I don't believe there is any ambiguity in how nodes are
> numbered anymore.
I'll have to study your patchset more closely tomorrow then.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
On Mon, 11 Feb 2008, Paul Jackson wrote:
> If things go as I hope, I expect to spend a couple of days this week
> reviving my earlier patch RFC that a couple of you on this cc list saw,
> concerning how nodes are numbered in mempolicy nodemasks. Certainly
> the work being done in these various
Lee wrote:
> We need to sort out with Andrew, Mel, Paul, ... the order in which these
> interdependent changes go in. Given such an order, I'm willing to merge
> them all up, test them, and post them [after running checkpatch, of
> course].
These patches look like good stuff at first glance.
On Mon, 11 Feb 2008, Lee Schermerhorn wrote:
> These patches look good--well, interesting, anyway. I'm "off on
> assignment" this week, so I won't get to review in detail, merge and
> test them until next...
>
If, by "interesting", you mean that they give the most power to the user
in
On Mon, 2008-02-11 at 07:30 -0800, David Rientjes wrote:
> With the evolution of mempolicies, it is necessary to support mempolicy
> mode flags that specify how the policy shall behave in certain
> circumstances. The most immediate need for mode flag support is to
> suppress remapping the
With the evolution of mempolicies, it is necessary to support mempolicy
mode flags that specify how the policy shall behave in certain
circumstances. The most immediate need for mode flag support is to
suppress remapping the nodemask of a policy at the time of rebind.
With the small number of
On Mon, 11 Feb 2008, Paul Jackson wrote:
If things go as I hope, I expect to spend a couple of days this week
reviving my earlier patch RFC that a couple of you on this cc list saw,
concerning how nodes are numbered in mempolicy nodemasks. Certainly
the work being done in these various
On Mon, 11 Feb 2008, Lee Schermerhorn wrote:
These patches look good--well, interesting, anyway. I'm off on
assignment this week, so I won't get to review in detail, merge and
test them until next...
If, by interesting, you mean that they give the most power to the user
in setting up
On Mon, 2008-02-11 at 07:30 -0800, David Rientjes wrote:
With the evolution of mempolicies, it is necessary to support mempolicy
mode flags that specify how the policy shall behave in certain
circumstances. The most immediate need for mode flag support is to
suppress remapping the nodemask of
David wrote:
With my patchset I don't believe there is any ambiguity in how nodes are
numbered anymore.
I'll have to study your patchset more closely tomorrow then.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul
Lee wrote:
We need to sort out with Andrew, Mel, Paul, ... the order in which these
interdependent changes go in. Given such an order, I'm willing to merge
them all up, test them, and post them [after running checkpatch, of
course].
These patches look like good stuff at first glance.
With the evolution of mempolicies, it is necessary to support mempolicy
mode flags that specify how the policy shall behave in certain
circumstances. The most immediate need for mode flag support is to
suppress remapping the nodemask of a policy at the time of rebind.
With the small number of
20 matches
Mail list logo
