public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Jackson <pj@sgi.com>
To: Michael Buesch <mbuesch@freenet.de>
Cc: akpm@osdl.org, steiner@sgi.com, dgc@sgi.com, Simon.Derr@bull.net,
	ak@suse.de, linux-kernel@vger.kernel.org, clameter@sgi.com
Subject: Re: [PATCH v2 02/07] cpuset use combined atomic_inc_return calls
Date: Thu, 9 Feb 2006 13:07:53 -0800	[thread overview]
Message-ID: <20060209130753.685ce15e.pj@sgi.com> (raw)
In-Reply-To: <200602092023.51547.mbuesch@freenet.de>

Michael wrote:
> Is this hunk really correct? I did not look into the code, but from
> the patch context it seems like it adds an inc here.

You have sharp eyes.

It doesn't matter much either way whether we increment or not here.

That's because this is in cpuset_init_early(), which is the -very- first
use of the global cpuset_mems_generation counter.  All other uses must
increment, so that they don't reuse a generation value someone else
used.  But we're first, so no possibility of reuse.

We can start with the first value, zero (0), or we can increment and
use one (1).

I changed it to atomic_inc_return() just to be consistent with all the
other locations that read this.  That way, if anyone else ever has to
get a value of cpuset_mems_generation and looks around to see how to do
it, they will see that it is always done using atomic_inc_return(), and
probably do it the same way, with minimum risk of confusion.

Just avoiding gratuitous differences in code that don't have a good
reason.

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

  reply	other threads:[~2006-02-09 21:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-09 18:54 [PATCH v2 01/07] cpuset cleanup not not operators Paul Jackson
2006-02-09 18:54 ` [PATCH v2 02/07] cpuset use combined atomic_inc_return calls Paul Jackson
2006-02-09 19:23   ` Michael Buesch
2006-02-09 21:07     ` Paul Jackson [this message]
2006-02-09 18:54 ` [PATCH v2 03/07] cpuset memory spread basic implementation Paul Jackson
2006-02-09 18:54 ` [PATCH v2 04/07] cpuset memory spread page cache implementation and hooks Paul Jackson
2006-02-09 18:54 ` [PATCH v2 05/07] cpuset memory spread slab cache implementation Paul Jackson
2006-02-09 18:54 ` [PATCH v2 06/07] cpuset memory spread slab cache optimizations Paul Jackson
2006-02-09 18:54 ` [PATCH v2 07/07] cpuset memory spread slab cache hooks 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=20060209130753.685ce15e.pj@sgi.com \
    --to=pj@sgi.com \
    --cc=Simon.Derr@bull.net \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=clameter@sgi.com \
    --cc=dgc@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbuesch@freenet.de \
    --cc=steiner@sgi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox