LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Paul Jackson <pj@sgi.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>,
	Andi Kleen <ak@suse.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [patch 1/6] mempolicy: convert MPOL constants to enum
Date: Wed, 27 Feb 2008 11:59:54 -0800 (PST)	[thread overview]
Message-ID: <alpine.DEB.1.00.0802271152570.313@chino.kir.corp.google.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0802271134150.1790@schroedinger.engr.sgi.com>

On Wed, 27 Feb 2008, Christoph Lameter wrote:

> On Mon, 25 Feb 2008, David Rientjes wrote:
> 
> >  struct mempolicy {
> >  	atomic_t refcnt;
> > -	short policy; 	/* See MPOL_* above */
> > +	unsigned short policy; 	/* See MPOL_* above */
> 
> The point here is to have a 16 bit value? There are no space savins due to 
> the alignment requirement of the union. Isnt it possible to use the enum 
> here? If not then what is the point of the enum?
> 

It was already a 16-bit value, that is unchanged, so no space savings is 
intended.

It is not possible to use the enum here because an additional unsigned 
short member to hold the mode flags is added to this struct later.  The 
increase in size of an int compared to an unsigned short would make the 
entire struct bigger; the alignment requirement of the union no longer 
prevents that.  After this patchset, it is 24 bytes in size while using 
unsigned short compared to 32 bytes while using int.

The enum is there to ensure MPOL_MAX is always accurate since it is now 
the sole way of testing for a proper mode being passed from the user, and
modes should be sequentially numbered.  A later change will add an array 
instance of a mempolicy_operations structure for the various modes.  It's 
just cleaner.

		David

  reply	other threads:[~2008-02-27 20:01 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-25 15:35 David Rientjes
2008-02-25 15:35 ` [patch 2/6] mempolicy: support optional mode flags David Rientjes
2008-02-25 15:35   ` [patch 3/6] mempolicy: add MPOL_F_STATIC_NODES flag David Rientjes
2008-02-25 15:35     ` [patch 4/6] mempolicy: add bitmap_onto() and bitmap_fold() operations David Rientjes
2008-02-25 15:35       ` [patch 5/6] mempolicy: add MPOL_F_RELATIVE_NODES flag David Rientjes
2008-02-25 15:35         ` [patch 6/6] mempolicy: update NUMA memory policy documentation David Rientjes
2008-02-26 17:34           ` Paul Jackson
2008-02-26 21:23             ` David Rientjes
2008-02-26  6:12         ` [patch 5/6] mempolicy: add MPOL_F_RELATIVE_NODES flag Paul Jackson
2008-02-26  6:45           ` David Rientjes
2008-02-26 17:44         ` Paul Jackson
2008-02-26 21:17           ` David Rientjes
2008-02-26 21:30             ` Paul Jackson
2008-02-26 21:27           ` Lee Schermerhorn
2008-02-27  1:17         ` David Rientjes
2008-02-27  1:31           ` David Rientjes
2008-02-27  2:30           ` Paul Jackson
2008-02-27 15:37           ` Lee Schermerhorn
2008-02-27 17:09             ` Paul Jackson
2008-02-28 21:08             ` David Rientjes
2008-02-26  5:46     ` [patch 3/6] mempolicy: add MPOL_F_STATIC_NODES flag Paul Jackson
2008-02-26  6:53       ` David Rientjes
2008-02-26 17:56     ` Paul Jackson
2008-02-26 21:02       ` David Rientjes
2008-02-26 21:32         ` Lee Schermerhorn
2008-02-26 21:54           ` David Rientjes
2008-02-26 22:08             ` Paul Jackson
2008-02-26 21:39         ` Paul Jackson
2008-02-26  3:20 ` [patch 1/6] mempolicy: convert MPOL constants to enum Paul Jackson
2008-02-26  3:35   ` David Rientjes
2008-02-26  4:02     ` Paul Jackson
2008-02-26  4:21       ` David Rientjes
2008-02-26  4:46         ` Paul Jackson
2008-02-27 19:35 ` Christoph Lameter
2008-02-27 19:59   ` David Rientjes [this message]
2008-03-01  0:44 David Rientjes
2008-03-03  7:17 ` Andrew Morton

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.0802271152570.313@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=linux-kernel@vger.kernel.org \
    --cc=pj@sgi.com \
    --subject='Re: [patch 1/6] mempolicy: convert MPOL constants to enum' \
    /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).