LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Paul Jackson <pj@sgi.com>
Cc: Lee.Schermerhorn@hp.com, mel@csn.ul.ie, ak@suse.de,
	linux-kernel@vger.kernel.org, ray-lk@madrabbit.org,
	kosaki.motohiro@jp.fujitsu.com, akpm@linux-foundation.org,
	clameter@sgi.com
Subject: Re: [RFC] bitmap onto and fold operators for mempolicy extensions
Date: Mon, 18 Feb 2008 16:46:28 -0800 (PST)	[thread overview]
Message-ID: <alpine.DEB.1.00.0802181637530.17993@chino.kir.corp.google.com> (raw)
In-Reply-To: <20080216123315.28685.5796.sendpatchset@jackhammer.engr.sgi.com>

On Sat, 16 Feb 2008, Paul Jackson wrote:

> Let's say an application has specified some mempolicies
> that presume 16 memory nodes, including say a mempolicy that
> specified MPOL_F_RELATIVE_NODES (cpuset relative) nodes 12-15.
> Then lets say that application is crammed into a cpuset that only
> has 8 memory nodes, 0-7.  If one just uses bitmap_onto(), this
> mempolicy, mapped to that cpuset, would ignore the requested
> relative nodes above 7, leaving it empty of nodes.  That's not
> good; better to fold the higher nodes down, so that some nodes
> are included in the resulting mapped mempolicy.  In this case,
> the mempolicy nodes 12-15 are taken modulo 8 (the weight of the
> mems_allowed of the confining cpuset), resulting in a mempolicy
> specifying nodes 4-7.
> 

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

In your example, the only way we know to use nodes_fold() is if the 
resultant of nodes_onto() has a weight of 0.  An MPOL_F_RELATIVE_NODES 
nodemask for 4-6, for example, works fine in your case of a cpuset with 
memory nodes 0-7 and no fold is required.

So it's easy enough to do this:

	case MPOL_INTERLEAVE:
		if (flags & MPOL_F_RELATIVE_NODES) {
			nodes_onto(pol->v.nodes, pol->user_nodemask,
				   cpuset_context_nmask);
			if (nodes_empty(pol->v.nodes))
				nodes_fold(pol->v.nodes,
					   pol->user_nodemask,
					   nodes_weight(cpuset_context_nmask));
		} else {
			...
		}
		break;

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())?

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.

		David

  parent reply	other threads:[~2008-02-19  0:46 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 [this message]
2008-02-19  6:05   ` Paul Jackson

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=alpine.DEB.1.00.0802181637530.17993@chino.kir.corp.google.com \
    --to=rientjes@google.com \
    --cc=Lee.Schermerhorn@hp.com \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=clameter@sgi.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mel@csn.ul.ie \
    --cc=pj@sgi.com \
    --cc=ray-lk@madrabbit.org \
    --subject='Re: [RFC] bitmap onto and fold operators for mempolicy extensions' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).