All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Jackson <pj@sgi.com>
To: David Rientjes <rientjes@google.com>
Cc: akpm@linux-foundation.org, clameter@sgi.com,
	Lee.Schermerhorn@hp.com, ak@suse.de,
	linux-kernel@vger.kernel.org
Subject: Re: [patch 3/4] mempolicy: add MPOL_F_STATIC_NODES flag
Date: Thu, 14 Feb 2008 04:09:18 -0600	[thread overview]
Message-ID: <20080214040918.d735e920.pj@sgi.com> (raw)
In-Reply-To: <alpine.DEB.1.00.0802101507400.11145@chino.kir.corp.google.com>

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() MPOL_F_* mode flags.
     */
    #define MPOL_FLAG_SHIFT (8)
    #define MPOL_MODE_MASK  ((1 << MPOL_FLAG_SHIFT) - 1)

    /* Flags for set_mempolicy */
    #define MPOL_F_STATIC_NODES     (1 << MPOL_FLAG_SHIFT)
    #define MPOL_MODE_FLAGS (MPOL_F_STATIC_NODES)   /* legal set_mempolicy() MPOL_* mode flags */

could be simplified, to:

    /*
     * Optional flags that modify nodemask numbering.
     */
    #define MPOL_F_RELATIVE_NODES (1<<14)	/* remapped relative to cpuset */
    #define MPOL_F_STATIC_NODES (1<<15)		/* unremapped physical masks */
    #define MPOL_MODE_FLAGS (MPOL_F_RELATIVE_NODES|MPOL_F_STATIC_NODES)
    						/* combined MPOL_F_* mask flags */

(really, that MPOL_FLAG_SHIFT is just unnecessary distracting detail.)

=========

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 applied again correctly if that node came back into our allowed
cpuset ?

        case MPOL_PREFERRED:
                if (!remap && !node_isset(pol->v.preferred_node, *newmask))
                        pol->v.preferred_node = -1;

=========

Instead of the double negative and the use of a new
word 'remap' meaning the opposite of STATIC, as in"

	int remap;
	...
	remap = !(mpol_flags(pol->policy) & MPOL_F_STATIC_NODES);
	...
		if (!remap)

How about something more direct, as in:

	int static_nodes;
	...
	static_nodes = mpol_flags(pol->policy) & MPOL_F_STATIC_NODES;
	...
		if (static_nodes)
		
Each additional logic inversion and additional name that isn't
trivially based on an existing name just makes this code more
difficult to read.

Of course, if we used bit fields for these additional flags,
instead of #defines and masks, the above would get even simpler,
eliminating the extra define's, and replacing the above three lines
with just the one line:

		if (pol->f_static_nodes)
		
But I already failed with that suggestion ... grumble, grumble ...

=========

Should the mpol_equal() algorithm change, in the case of either
MPOL_F_RELATIVE_NODES or MPOL_F_STATIC_NODES, to checking
user_nodemask equality, -instead- of the "switch(mode)"
mode specific tests?

=========

Could we have mpol_to_str() mark policies which are
MPOL_F_RELATIVE_NODES or MPOL_F_STATIC_NODES?  Perhaps
by adding a suffix of "|relative" or "|static" or some
such.


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

  parent reply	other threads:[~2008-02-14 10:09 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-11 15:30 [patch 1/4] mempolicy: convert MPOL constants to enum David Rientjes
2008-02-11 15:30 ` [patch 2/4] mempolicy: support optional mode flags David Rientjes
2008-02-11 15:30   ` [patch 3/4] mempolicy: add MPOL_F_STATIC_NODES flag David Rientjes
2008-02-11 15:30     ` [patch 4/4] mempolicy: update NUMA memory policy documentation David Rientjes
2008-02-11 16:10       ` Randy Dunlap
2008-02-11 20:06         ` [patch 4/4 v2] " David Rientjes
2008-02-11 20:14           ` Randy Dunlap
2008-02-11 18:25     ` [patch 3/4] mempolicy: add MPOL_F_STATIC_NODES flag KOSAKI Motohiro
2008-02-11 19:56       ` David Rientjes
2008-02-13  0:25         ` Lee Schermerhorn
2008-02-13  0:57           ` David Rientjes
2008-02-11 19:34     ` Christoph Lameter
2008-02-13  0:22     ` Lee Schermerhorn
2008-02-13  3:52       ` Paul Jackson
2008-02-13  4:03         ` David Rientjes
2008-02-13  4:13           ` Paul Jackson
2008-02-13  4:23             ` David Rientjes
2008-02-13  8:03               ` Paul Jackson
2008-02-13  9:36                 ` David Rientjes
2008-02-13 16:01                   ` Lee Schermerhorn
2008-02-13 18:48                     ` David Rientjes
2008-02-13 18:58                       ` Paul Jackson
2008-02-13 19:05                       ` Lee Schermerhorn
2008-02-13 19:17                         ` David Rientjes
2008-02-13 17:04                   ` Paul Jackson
2008-02-13 19:02                     ` David Rientjes
2008-02-13 20:29                       ` Paul Jackson
2008-02-13 21:35                         ` David Rientjes
2008-02-14 11:12                           ` Paul Jackson
2008-02-14 12:27                           ` Paul Jackson
2008-02-14 10:26                         ` Paul Jackson
2008-02-14 19:45                           ` David Rientjes
2008-02-15 10:19                             ` Paul Jackson
2008-02-15 20:14                               ` David Rientjes
2008-02-13  4:18       ` David Rientjes
2008-02-13  5:06         ` David Rientjes
2008-02-13 15:15           ` Lee Schermerhorn
2008-02-13 16:14         ` Lee Schermerhorn
2008-02-13 19:12           ` David Rientjes
2008-02-14 10:09     ` Paul Jackson [this message]
2008-02-14 19:40       ` David Rientjes
2008-02-15  1:44         ` David Rientjes
2008-02-15 10:00           ` Paul Jackson
2008-02-14 21:38       ` David Rientjes
2008-02-15  9:27         ` Paul Jackson
2008-02-15 20:23           ` David Rientjes
2008-02-15 20:32             ` David Rientjes
2008-02-15 23:45             ` Paul Jackson
2008-02-15 23:55               ` David Rientjes
2008-02-16  0:11                 ` Paul Jackson
2008-02-11 16:36   ` [patch 2/4] mempolicy: support optional mode flags Lee Schermerhorn
2008-02-11 19:34     ` David Rientjes
2008-02-12 15:31       ` Lee Schermerhorn
2008-02-12 19:14         ` David Rientjes
2008-02-11 20:55     ` Paul Jackson
2008-02-11 21:52       ` David Rientjes
2008-02-11 21:57         ` Paul Jackson
2008-02-13  0:14   ` Lee Schermerhorn
2008-02-13  0:25     ` David Rientjes
2008-02-11 18:45 ` [patch 1/4] mempolicy: convert MPOL constants to enum Andi Kleen
2008-02-11 19:25   ` David Rientjes
2008-02-11 19:32 ` Christoph Lameter
2008-02-11 19:40   ` David Rientjes
2008-02-11 19:48     ` Christoph Lameter
2008-02-11 20:02       ` David Rientjes
2008-02-11 20:45         ` Christoph Lameter
2008-02-13  0:10 ` Lee Schermerhorn
2008-02-13  0:31   ` Paul Jackson
2008-02-13  0:53     ` David Rientjes
2008-02-13  1:04     ` Christoph Lameter
2008-02-13  1:28       ` Paul Jackson
2008-02-13  1:32       ` Paul Jackson
2008-02-13  2:00         ` David Rientjes
2008-02-13  2:22           ` Paul Jackson
2008-02-13  2:42             ` David Rientjes
2008-02-13  2:59               ` Paul Jackson
2008-02-13  3:17                 ` David Rientjes
2008-02-13  3:22                   ` 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=20080214040918.d735e920.pj@sgi.com \
    --to=pj@sgi.com \
    --cc=Lee.Schermerhorn@hp.com \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=clameter@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rientjes@google.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.