LKML Archive on
help / color / mirror / Atom feed
From: Paul Jackson <>
To: David Rientjes <>
Subject: Re: [RFC] bitmap onto and fold operators for mempolicy extensions
Date: Tue, 19 Feb 2008 00:05:29 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

David wrote:
> So what is the MPOL_F_RELATIVE_NODES behavior?  Is it a combination of 
> nodes_onto() and nodes_fold()?

MPOL_F_RELATIVE_NODES should always combination of nodes_onto() and

The reason I say that is consistency with the end cases.  That is,
we need fold in the case that no requested nodes have numbers
smaller than the weight of the cpusets mems_allowed.  At the opposite
extreme, when -all- requested node numbers are smaller than the weight
of mems_allowed, fold has no affect, so it's fine to use there.  And
for the in between cases, when some requested nodes are smaller and
some not, fold is one possible reasonable answer.  So use it everywhere
for consistency.

> So it's easy enough to do this:
> 		if (flags & MPOL_F_RELATIVE_NODES) {
> 			nodes_onto(pol->v.nodes, pol->user_nodemask,
> 				   cpuset_context_nmask);
> 			if (nodes_empty(pol->v.nodes))

I hate any more special cases than I have to have -- so not that way.

> But what if we require a combination?  Say the user asked for a policy of 
> MPOL_INTERLEAVE | MPOL_F_RELATIVE_NODES over nodes 4-8 in a cpuset 
> constrained to mems 0-7?  Should the resultant be 0,4-7 (combination of 
> nodes_onto() and nodes_fold()) or simply be 4-7 (just nodes_onto())?

All fold, all the time ;).  So this one should be 0,4-7.

> And what if the MPOL_INTERLEAVE | MPOL_F_RELATIVE_NODES nodemask is 0,4-8 
> in the same cpuset constrained to mems 0-7?  Should the resultant be
>  - 0,4-7 (nodes_onto() and nodes_fold()),
>  - 0,4-7 (just nodes_onto()), or
>  - 0-1,4-7 (nodes_onto(), nodes_fold(), and shift)?
> The last option, 0-1,4-7, is the only one that preserves the same weight 
> as the relative nodemask.

Again, 0,4-7.

Weight preservation is not a goal here, and would require special cases.

If someone crams a five pound cpuset relative memory policy into a two
poound cpuset, they will likely loose weight.  What matters in that
case is that things plod along without too much distress, and that
when the job is restored to a proper size cpuset, its memory policies
recover their full health.

                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <> 1.940.382.4214

      reply	other threads:[~2008-02-19  6:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-16 12:33 Paul Jackson
2008-02-16 13:38 ` KOSAKI Motohiro
2008-02-16 16:46   ` Paul Jackson
2008-02-17  2:39     ` KOSAKI Motohiro
2008-02-17  3:31       ` Paul Jackson
2008-02-19  0:46 ` David Rientjes
2008-02-19  6:05   ` Paul Jackson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [RFC] bitmap onto and fold operators for mempolicy extensions' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).